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RTO  is  the  single  focus  in  NATO  for  Defence  Research  and  Technology  activities.  Its  mission  is  to  conduct  and  promote 
co-operative  research  and  information  exchange.  The  objective  is  to  support  the  development  and  effective  use  of 
national  defence  research  and  technology  and  to  meet  the  military  needs  of  the  Alliance,  to  maintain  a  technological 
lead,  and  to  provide  advice  to  NATO  and  national  decision  makers.  The  RTO  performs  its  mission  with  the  support  of  an 
extensive  network  of  national  experts.  It  also  ensures  effective  co-ordination  with  other  NATO  bodies  involved  in  R&T 
activities. 


RTO  reports  both  to  the  Military  Committee  of  NATO  and  to  the  Conference  of  National  Armament  Directors.  It 
comprises  a  Research  and  Technology  Board  (RTB)  as  the  highest  level  of  national  representation  and  the  Research  and 
Technology  Agency  (RTA),  a  dedicated  staff  with  its  headquarters  in  Neuilly,  near  Paris,  France.  In  order  to  facilitate 
contacts  with  the  military  users  and  other  NATO  activities,  a  small  part  of  the  RTA  staff  is  located  in  NATO 
Headquarters  in  Brussels.  The  Brussels  staff  also  co-ordinates  RTO’s  co-operation  with  nations  in  Middle  and  Eastern 
Europe,  to  which  RTO  attaches  particular  importance  especially  as  working  together  in  the  field  of  research  is  one  of  the 
more  promising  areas  of  co-operation. 


The  total  spectrum  of  R&T  activities  is  covered  by  the  following  7 
•  AVT  Applied  Vehicle  Technology  Panel 
Human  Factors  and  Medicine  Panel 
Information  Systems  Technology  Panel 
NMSG  NATO  Modelling  and  Simulation  Group 
SAS  Studies,  Analysis  and  Simulation  Panel 
Systems  Concepts  and  Integration  Panel 
Sensors  and  Electronics  Technology  Panel 
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bodies: 


These  bodies  are  made  up  of  national  representatives  as  well  as  generally  recognised  ‘world  class’  scientists.  They  also 
provide  a  communication  link  to  military  users  and  other  NATO  bodies.  RTO’s  scientific  and  technological  work  is 
carried  out  by  Technical  Teams,  created  for  specific  activities  and  with  a  specific  duration.  Such  Technical  Teams  can 
organise  workshops,  symposia,  field  trials,  lecture  series  and  training  courses.  An  important  function  of  these  Technical 
Teams  is  to  ensure  the  continuity  of  the  expert  networks. 


RTO  builds  upon  earlier  co-operation  in  defence  research  and  technology  as  set-up  under  the  Advisory  Group  for 
Aerospace  Research  and  Development  (AGARD)  and  the  Defence  Research  Group  (DRG).  AGARD  and  the  DRG  share 
common  roots  in  that  they  were  both  established  at  the  initiative  of  Dr  Theodore  von  Karman,  a  leading  aerospace 
scientist,  who  early  on  recognised  the  importance  of  scientific  support  for  the  Allied  Armed  Forces.  RTO  is  capitalising 
on  these  common  roots  in  order  to  provide  the  Alliance  and  the  NATO  nations  with  a  strong  scientific  and  technological 
basis  that  will  guarantee  a  solid  base  for  the  future. 
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C3I  and  Modelling  and  Simulation  (M&S) 

Interoperability 

(RT  O-MP-MSG-022) 

Executive  Summary 

The  NATO  Modelling  and  Simulation  Group  (NMSG)  Conference  (MSG-022)  “Command,  Control, 
Communications  and  Intelligence  (C3)  and  Modelling  &  Simulation  (M&S)  Interoperability”  was 
conducted  in  Antalya,  Turkey  from  9  to  10  October  2003.  All  sessions  of  the  Conference  were 
unclassified.  The  Conference  audience  of  128  persons  included  experts  from  NATO  countries,  Partners- 
for-Peace  (PfP),  as  well  as  invited  nations.  Nineteen  papers  were  selected  for  presentation.  In  addition, 
two  keynote  presentations  and  a  capstone  paper  were  given. 

Interoperability  of  Command,  Control,  Communications  and  Intelligence  (C3I)  and  Modelling  & 
Simulation  (M&S)  systems  is  a  necessary  requirement  for  effective  and  efficient  support  of  future  military 
operations,  including;  procurement,  acquisition,  test  and  evaluation,  training,  and  application  of  necessary 
functionality  within  the  ongoing  operation.  In  order  to  be  able  to  support  this  task,  a  close  understanding 
and  knowledge  of  the  software  architecture,  the  communications  protocols,  possible  interfaces,  data  and 
object  models,  and  the  management  procedures  used  on  the  C3I  and  M&S  side  is  mandatory. 

The  majority  of  the  actual  solutions  are  interface  driven  to  link  stove-piped  developed  legacy  systems. 
The  use  of  common  reference  models  facilitating  the  necessary  data  alignment  and  information  exchange 
is  a  first  step  to  broader  and  reusable  solutions.  Newer  systems  with  configurable  interfaces  making  use  of 
these  technical  potentials  are  pointing  to  the  next  set  of  solutions. 

Although  the  number  of  engineering  solutions  linking  C3I  and  M&S  systems  is  relatively  high,  the 
amount  of  “documented  lesson  learned”  is  relatively  small.  Most  solutions  are  ad-hoc,  not  following  a 
common  or  general  scheme.  In  order  to  establish  a  standard  way  -  which  increases  reusability  and 
collaboration  and  reduces  costs  and  risks  of  affected  projects  and  programmes  -  this  has  to  change. 
Documentation  of  applied  methods  and  procedures  must  be  captured  and  evaluated. 

Technical  Reference  Models  (TRM),  such  as  the  one  developed  by  the  Simulation  Interoperability 
Standards  Organization  (SISO),  are  applicable  to  NATO  standards  and  will  facilitate  the  perception  of 
common  migration  paths  and  reusability  of  legacy  components  in  future  systems.  National  solutions  can 
be  mapped  to  these  TRMs  to  facilitate  joint  and  combined  C3I  system  and  federation  planning. 

The  Command  and  Control  Information  Exchange  Data  Model  (C2IEDM),  which  is  the  NATO  Standard 
Allied  Data  Publication  No.  32  (ADatP-32)  and  the  Data  Model  of  Choice  for  the  Multinational 
Interoperability  Programme  (MIP)  connecting  NATO’s  Command  and  Control  systems  and  the  basis  for 
various  national  C3I  systems,  is  successfully  used  for  data  alignment  in  various  national  projects. 
C2IEDM  was  not  only  applied  to  C3I  systems,  but  also  to  M&S  data  alignment.  As  the  NATO  Data 
Administration  Group  (NDAG)  is  already  using  the  C2IEDM  for  data  management  for  C3I  systems,  the 
extension  to  M&S  systems  is  perceived  as  a  valuable  option. 

Future  interoperability  standards  will  depend  much  more  on  commercial  solutions  than  it  has  been  the  case 
in  the  past.  New  standards  as  the  next  generation  of  the  Unified  Modelling  Language  version  2.0  (UML 
2.0),  the  Extensible  Mark-up  Language  (XML),  web  services,  and  the  Model  Driven  Architecture  (MDA) 
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are  applicable  to  C3I  systems  as  well  as  to  M&S  systems.  They  support  actual  developments  to  make  use 
of  internet  technologies  -  which  are  in  particular  observable  in  the  United  States  where  the  definition  of 
development  of  the  Global  Information  Grid  (GIG)  was  recently  initiated. 

Finally,  a  closer  relationship  between  the  NATO  M&S  Group  and  the  Simulation  Interoperability 
Standards  Organization  (SISO),  in  particular  the  observation,  and  where  appropriate,  active  participation 
in  study  groups  and  product  development  groups,  is  likely  to  support  the  process  of  gaining  C3I  and  M&S 
interoperability  effectively.  A  formal  liaison  -  based  upon  the  initial  informal  relationship  established  by 
Dr.  Jean-Louis  Igarza,  first  chief  scientist  of  the  NMSG  -  will  ensure  that  the  NMSG  is  aware  of  the  latest 
developments  of  the  simulation  standardisation  world  and  can  influence  the  new  standards  by  bringing  in 
the  NMSG  requirements  as  early  as  possible,  i.e.,  before  the  standards  are  established.  A  closer 
relationship  with  EUCLID  projects  also  may  be  valuable. 

In  summary,  the  conference  was  very  successful.  State  of  the  art  solutions  as  well  as  ideas  and 
requirements  for  necessary  future  research  and  development  were  presented  and  the  views  of  the  armed 
forces,  industry,  government,  and  academia  were  discussed.  The  papers  presented  during  the  conference 
provided  a  good  overview  of  what  has  been  done  in  NATO  and  NATO/PfP  nations,  what  is  the  state  of  the 
art,  and  the  next  steps. 
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Interoperability  entre  le  C3I  et  la  modelisation  et 

la  simulation  (M&S) 

(RTO-MP-MSG-022) 


Synthese 

Une  conference  sur  «  L'interoperabilite  du  C3I  et  de  la  modelisation  »  a  ete  organisee  par  le  Groupe 
OTAN  sur  la  modelisation  et  la  simulation  (NMSG),  a  Antalya,  en  Turquie,  les  9  et  10  octobre  2003. 
Toutes  les  sessions  de  la  conference  etaient  non  classifies.  L’assistance,  au  nombre  de  128  personnes, 
comprenait  des  specialistes  des  pays  membres  de  l’OTAN,  des  pays  du  PfP,  ainsi  que  des  pays  invites. 
Dix-neuf  communications  ont  fait  l’objet  d’une  selection.  En  outre,  deux  discours  d’ouverture  et  une 
allocation  de  cloture  ont  ete  prononces. 

L’interoperabilite  entre  les  systemes  de  commandement,  controle,  communications  et  renseignement  (C3I) 
et  les  systemes  de  modelisation  et  de  simulation  (M&S)  est  une  condition  indispensable  au  soutien  reel  et 
efficace  des  futures  operations  militaires,  a  savoir  :  approvisionnement,  acquisition,  essais  et  evaluation, 
entrainement  et  mise  en  oeuvre  des  fonctions  necessaires  dans  le  cadre  des  operations  en  cours.  Le  soutien 
de  l’interoperabilite  passe  par  une  bonne  comprehension  et  une  connaissance  appro fondie  des 
architectures  logicielles,  des  protocoles  de  communication,  des  interfaces  possibles,  des  modeles  de 
donnees  et  d’objets,  ainsi  que  des  procedures  de  gestion  utilisees  pour  le  C3I  et  la  M&S. 

La  majorite  des  solutions  actuellement  proposees  font  appel  a  des  interfaces  pour  etablir  des  liens  entre 
systemes  classiques  distincts.  Dans  un  premier  temps,  la  mise  en  oeuvre  de  modeles  de  reference 
commune,  facilitant  l’echange  et  l’alignement  des  donnees  necessaires  ouvrirait  la  voie  a  des  solutions 
reutilisables  plus  generates.  Des  systemes  plus  recents,  dotes  d’ interfaces  configurables  qui  exploitent  ces 
possibilites  techniques,  laissent  prevoir  de  nouvelles  solutions. 

Malgre  l'abondance  relative  de  solutions  techniques  s'appliquant  au  C3I  et  a  la  M&S,  relativement  peu  de 
documents  existent  sur  "les  enseignements  tires"  de  cette  experience.  La  plupart  des  solutions  sont  du 
type  ad  hoc,  et  ne  suivent  pas  un  schema  commun  ou  general.  Cette  situation  doit  changer  en  faveur 
d’une  approche  standard  -  qui  donnerait  plus  de  possibilites  de  reutilisation  et  de  cooperation  et 
permettrait  de  reduire  les  couts  et  les  risques  pour  les  projets  et  les  programmes  affectes.  II  faudra  saisir 
et  evaluer  les  methodes  et  procedures  a  appliquer. 

Des  modeles  de  reference  techniques  (TRM),  comme  celui  developpe  par  l’Organisation  de  normalisation 
de  l’interoperabilite  en  matiere  de  simulation  (SISO),  sont  applicables  aux  normes  de  l’OTAN  et 
faciliteront  la  perception  de  chemins  de  migration  communs,  ainsi  que  la  reutilisation  d’ elements 
classiques  dans  les  systemes  futurs.  Des  solutions  nationales  peuvent  etre  etablies  en  fonction  de  ces 
TRM  afm  de  faciliter  la  conception  de  federations  et  de  systemes  C3I  interarmees  et  multinationaux. 

Le  modele  d’echange  d'informations  de  commandement  et  controle  (C2IEDM),  materialise  par  la 
publication  normalisee  ADatP-32  de  l’OTAN,  qui  est  le  modele  de  donnees  de  choix  du  Programme 
d’interoperabilite  multinationale  (MIP)  reliant  les  systemes  de  commandement  et  controle  de  l'OTAN, 
ainsi  que  la  base  de  differents  systemes  C3I  nationaux,  a  ete  mis  en  oeuvre  avec  succes  pour  l'alignement 
des  donnees  dans  le  cadre  de  plusieurs  projets  nationaux.  Le  C2IEDM  n’a  pas  ete  applique  uniquement  a 
des  systemes  C3I,  mais  aussi  a  l’alignement  de  donnees  M&S.  Etant  donne  que  le  Groupe  pour 
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1’ administration  des  donnees  de  l’OTAN  (NDAG)  utilise  deja  le  C2IEDM  pour  la  gestion  de  donnees  de 
systemes  C3I,  son  extension  aux  systemes  M&S  est  pcrguc  comme  une  option  interessante. 

A  l’avenir,  les  normes  d’interoperabilite  dependront  beaucoup  plus  de  solutions  commerciales  que  par  le 
passe.  Les  nouvelles  normes,  telles  que  la  prochaine  generation  du  Langage  de  modelisation  unifie 
Version  2.0  (UML  2.0),  le  Langage  de  balisage  extensible  (XML),  les  services  du  Web,  et  les 
Architectures  guidees  par  modele  (MDA),  sont  applicables  aux  systemes  C3I  ainsi  qu'aux  systemes  M&S. 
Ils  supportent  les  developpements  actuels  destines  a  exploiter  les  technologies  de  l’lntemet  -  qui  sont 
surtout  disponibles  aux  Etats-Unis,  ou  le  developpement  du  Reseau  global  de  l'information  (GIG)  a 
recemment.  ete  lance. 

La  creation  de  liens  plus  etroits  entre  le  groupe  M&S  de  l’OTAN  et  ^Organisation  de  normalisation  de 
l'interoperabilite  en  matiere  de  simulation  (SISO),  et  en  particulier  l’observation,  ainsi  que,  le  cas  echeant, 
la  participation  active  a  des  groupes  d’ etude  et  des  groupes  de  developpement  de  produits,  permettrait  de 
faire  avancer  l'interoperabilite  efficace  entre  le  C3I  et  la  M&S.  Une  liaison  officielle  -  basee  sur  les 
relations  officieuses  etablies  par  le  Dr.  Jean-Louis  Igarza,  le  principal  expert  scientifique  aupres  du  NMSG 
-  permettra  au  NMSG  d’etre  informe  des  derniers  developpements  dans  le  domaine  de  la  normalisation  de 
la  simulation.  Le  groupe  pourra  ainsi  faire  valoir  ses  souhaits  en  matiere  de  normalisation  avant 
l’etablissement  des  normes.  II  serait  sans  doute  interessant  aussi  d’etablir  des  liens  avec  des  projets 
EUCLID. 

Pour  resumer,  la  conference  a  ete  tres  reussie.  Des  solutions  faisant  appel  a  des  techniques  de  pointe  ont 
ete  presentees,  ainsi  que  des  propositions  et  des  besoins  en  matiere  de  projets  de  recherche  futurs.  Les 
points  de  vue  des  militaires,  des  industriels,  des  representants  des  gouvemements  et  des  universitaires  ont 
ete  debattus.  Les  communications  presentees  lors  de  la  conference  ont  foumi  un  bon  aperpu  des  travaux 
realises  dans  les  pays  de  l’OTAN,  ainsi  que  dans  les  pays  du  PPP,  de  l’etat  actuel  des  connaissances  et  des 
initiatives  qui  restent  a  prendre. 
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OVERVIEW 

The  NATO  Modelling  and  Simulation  Group  (NMSG)  Conference  (MSG-022)  “ Command ,  Control, 

Communications  and  Intelligence  (C3)  and  Modelling  &  Simulation  (M&S)  Interoperability”  was 
conducted  in  Antalya,  Turkey  from  9  to  10  October  2003.  All  sessions  of  the  Conference  were 
unclassified.  The  Conference  audience  of  128  persons  included  experts  from  NATO  countries,  Partners- 
for-Peace  (PfP)  nations,  as  well  as  invited  nations. 

Out  of  the  30  submitted  abstracts,  19  Papers  were  selected  for  presentation.  In  addition,  two  keynote 
presentations  and  a  capstone  paper  were  given.  This  technical  evaluation  report  summarizes  the  core 
ideas  and  results  presented  in  this  wide  variety  of  valuable  contributions  from  NATO  countries,  PfP 
nations,  and  invited  nations.  In  addition,  for  each  category,  the  report  provides  an  overview  of  the 
discussions  conducted  during  the  conference  following  each  presentation. 


INTRODUCTION 

The  importance  of  Modelling  and  Simulation  (M&S)  is  now  largely  recognised  within  NATO.  Among 
various  military  applications  of  M&S  within  the  Alliance,  Operational  Support  and  Training  are  identified 
as  high  priority  areas.  In  parallel  NATO  has  developed  an  important  activity  in  the  Command,  Control, 
Communication  and  Intelligence  (C31)  Systems  as  the  backbone  support  of  military  activities. 

Whilst  C31  and  M&S  domains  have  many  technical  similarities,  they  have  developed  along  separate  tracks 
in  the  Alliance,  as  in  many  nations,  sometimes  differing  by  their  purposes  and  priorities.  As  an  example, 
different  standards  have  been  developed  in  parallel  and  are  not  largely  understood  and  shared  in  both 
communities.  The  NATO  Modelling  and  Simulation  Master  Plan  -  the  capstone  document  for  M&S 
systems  -  does  not  mention  the  NATO  C3  Technical  Architecture  -  the  capstone  document  for  C3I 
systems  -  and  vice  versa.  For  the  efficient  support  of  planning,  training,  and  executing  of  operations,  as 
well  as  NATO  procurement  and  doctrine  development,  this  gap  should  be  closed.  Consequently,  the  main 
objective  of  this  conference  was  to  contribute  to  a  better  understanding  of  and  an  improvement  in 
interoperability  between  C31  and  M&S  systems  as  a  first  step  towards  a  common  information  technology 
(IT)  infrastructure  supporting  M&S  as  well  as  C31  systems,  thus,  overcoming  the  shortfalls  of  interface 
driven  solutions.  Following  topics  were  given  as  a  guideline  for  the  authors: 

•  Lessons  learned  from  past  experience  in  linking  C31  and  M&S, 

•  Current  Joint  use  of  C31  and  M&S  in  Computer  Assisted  Exercises  (CAX), 
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•  Interoperability  and  data  standards, 

•  Future  projects. 

In  addition,  the  conference  addressed  the  themes  of  research,  development  and  cost-effective  co-operative 
application  of  C3I  and  M&S  systems.  Furthermore,  the  Data  Consistency  and  Translation  between  C3I 
and  Simulations  was  perceived  to  be  a  first  valuable  step  into  this  direction. 

That  these  topics  are  generally  of  great  interest  can  already  be  derived  from  the  number  of  abstracts 
submitted  following  the  call  for  papers.  Twice  the  number  of  possible  presentations  was  evaluated,  and 
unfortunately  not  every  valuable  abstract  could  be  accepted.  The  resulting  paper  selection  consequently 
represents  the  leading  edge  of  research,  development,  and  application  of  methods,  procedures  and  IT 
solutions  supporting  C3I  and  M&S  Interoperability  within  NATO  and  PfP  nations. 

The  Keynote  speakers  supported  this  perspective: 

•  Brigadier  General  B.  Pekar,  Turkish  General  Staff,  stressed  the  necessity  of  appropriate  training 
for  efficient  operational  availability.  Modelling  and  Simulation  is  the  most  economic  and 
appropriate  support  to  fulfil  this  requirement.  The  integration  of  Command  and  Control  systems 
to  enable  “Train  as  they  fight”  is  a  cornerstone  of  realistic  training.  A  tight  relation  between 
armed  forces,  industry  and  academia  is  necessary  to  support  these  efforts.  The  NATO  fellowship 
programme,  and  in  particular  the  Turkish  Canadian  cooperation  in  the  C3I  and  M&S 
Interoperability  domain,  was  stressed  as  another  important  factor  by  General  Pekar. 

•  Dr.  F.  A.  Yarman,  General  Manager  of  Havelsan,  showed  the  potentials  of  the  Turkish  M&S 
market  from  the  local  defence  industry  to  highlight  the  economic  importance  of  the  issue  dealt 
with  in  this  conference.  He  used  the  simulation  based  acquisition  idea  to  show  the  benefits  of 
using  M&S  stressing  the  importance  of  the  scientific  process  of  sound  modelling.  Synthetic 
environments,  physical  modelling,  computer  generated  forces,  and  scenario  generations,  and  after 
action  review  and  replay  were  presented  as  the  core  domains  of  necessary  military  M&S  efforts. 
C3I  must  be  an  integrated  part  of  the  resulting  architecture.  Furthermore,  Dr.  Yarman  stressed  the 
necessity  of  standards  for  effective  reusability  and  collaboration  and  gave  examples  for  migration 
procedures. 

All  presentations  given  during  this  conference  perceived  the  role  of  M&S  in  Training  and  Education  to  be 
established,  in  particular  the  use  of  M&S  for  CAX.  CDRE  Jon  Welch,  NATO  Allied  Command 
Transformation  (ACT),  Norfolk,  Virginia,  U.S.A.,  presented  the  important  new  role  of  M&S  in 
transformation  in  his  capstone  speech.  NATO  is  transforming  to  fulfil  its  new  mission.  To  steer  the 
process  and  align  sub-processes,  the  ACT  is  being  established.  Within  the  ACT,  in  particular  Joint 
Education  &  Training  and  Joint  Concept  Experimentation  will  need  M&S  support  and  has  C3I  and  M&S 
interoperability  as  a  necessary  requirement  to  fulfil  the  new  tasks  effectively  and  efficiently  and  to 
establish  the  envisioned  NATO  Transformation  Process.  In  summary,  M&S  will  play  a  pivotal  role  in 
transformation. 

Within  the  following  sections,  the  core  ideas  and  discussion  results  are  grouped  by  the  topics  given  in  the 
authors’  guideline.  When  writing  this  technical  evaluation  report  it  was  not  intended  to  recite  paper 
abstracts  or  give  pure  summaries,  but  to  show  the  general  developments  and  common  ideas  allowing  the 
analyses  of  trends  within  NATO/PfP  nations  and  other  invited  nations.  Therefore,  only  the  contributions 
to  this  objective  are  addressed  in  this  report.  As  previously  mentioned,  all  the  papers  are  very  valuable 
and  it  is  highly  recommended  to  read  and  analyse  all  underlying  trends  and  references,  in  particular  when 
dealing  with  special  issues.  The  papers  will  be  referenced  using  the  numbers  assigned  in  the  official 
programme,  such  as  [P-01]  to  reference  to  the  paper  “Overview  of  Recent  Findings  of  the  Study  Groups  of 
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LESSONS  LEARNED  FROM  PAST  EXPERIENCES  IN  LINKING  C3I  AND  M&S 

The  domain  of  linking  C3I  and  M&S  systems  is  recognized  more  and  more  as  an  engineering  task  in  the 
NATO  nations  -  and  in  non-NATO  nations  as  well  -  and  therefore  lessons  learned  are  now  being 
generated.  Examples  of  such  lessons  learned  are  summarized  in  [P-01]  and  [P-02],  However,  a  standard 
way  to  link  C3I  and  M&S  is  not  yet  established.  The  SISO  Technical  Reference  Model  for  C4ISR  and 
Simulation  System  Interoperability  presented  in  [P-01,  P-18]  is  a  first  promising  step,  but  actually  most 
link  solutions  are  “one  of  a  kind”  and  in  general  not  easily  reusable. 

Another  often  observed  shortcoming  is  documented  in  [P-02],  and  the  discussion  showed  the  validity  of 
these  perceptions  as  well:  In  general,  prototype  developers  are  neither  HLA  nor  C3I  experts,  which  results 
in  proprietary  solutions.  The  use  of  standards  is  seldom  the  case  with  prototype  developments,  and 
unfortunately,  many  M&S  systems  in  operational  use  are  still  on  the  prototypical  implementation  level. 
Standardization  is  often  seen  as  something  that  can  be  dealt  with  later  in  the  project,  i.e.,  after  the  proof  of 
feasibility.  This  procedure  generally  makes  standardisation  unnecessarily  costly,  as  re -implementations 
and  updates  are  more  expensive  than  using  the  standard  from  the  beginning  of  the  project.  In  particular 
recommended  or  mandated  standards,  such  as  given  in  the  NATO  C3  Technical  Architecture  and  the 
NATO  M&S  Master  Plan,  should  already  be  used  in  the  initialisation  phase.  The  increasing  use  of 
testbeds  with  necessary  integration  capabilities  may  help  to  overcome  this  shortcoming. 

However,  it  would  be  naive  to  assume  that  coupling  of  C3I  and  M&S  systems  would  be  a  pure 
engineering  problem.  Even  if  we  could  solve  the  linkage  without  additional  challenges,  the  resulting 
solutions  are  not  necessarily  sufficient.  This  was  pointed  out  in  [P-09].  Actually,  many  M&S  challenges 
have  to  be  solved,  such  as  multi-resolution  challenges.  The  discussion  showed  furthermore,  that 
increasingly  multilevel-security  challenges  have  to  be  solved  as  well. 

For  coping  effectively  and  efficiently  with  C3I  and  M&S  interoperability  issues,  deep  knowledge  of  IT 
architectures,  data  and  object  models,  and  applied  management  procedures  of  both  communities  is 
mandatory.  A  good  overview  of  most  relevant  NATO  C3  interoperability  standards  and  the  applicability 
of  respective  reference  models  are  given  in  [P-1 8],  The  standards  referred  to  in  this  paper  are  a  minimal 
set  of  necessary  knowledge  of  M&S  experts  responsible  for  NATO  C3I  and  M&S  interoperability. 


CURRENT  JOINT  USE  OF  C3I  AND  M&S  IN  CAX 

The  M&S  application  domain  of  training  and  education,  in  particular  Computer  Assisted  Exercises 
(CAX),  is  likely  to  be  the  most  visible  mature  application  for  NATO.  Keynotes  and  presentations 
supported  this  view. 

In  [P-02]  the  NATO  CAX  “Cannon  Cloud  2002”  was  evaluated  to  illustrate  the  use  of  C3I  and  M&S 
within  NATO  for  training  and  education.  Cannon  Cloud  2002  successfully  demonstrated  the  utility  of 
integrating  entity-level  simulations  into  an  operational  level  CAX  using  distributed  techniques.  [P-02] 
used  Cannon  Cloud  2002  as  a  case  study  highlighting  the  main  domains  of  C3I  and  M&S  interoperability, 
which  includes  typical  simulation-to-simulation  challenges,  such  as  aggregation  and  other  multiple 
resolution  issues.  The  similar  national  use  of  C3I  and  M&S  supporting  CAX  was  the  topic  of  various 
papers,  including  [P-05,  P-06,  P-09]. 

NATO  politics  require  that  NATO  partners  and  allies  participate  in  common  exercises.  Logically,  new 
NATO  partners  and  PfP  nations  use  CAX  to  gain  experience  in  the  application  of  NATO  doctrine  and 
procedures.  [P-06]  shows  how  this  has  been  done  in  Slovakia  in  an  exemplifying  way.  These  new  CAX 
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systems  and  federations  are  normally  planned  with  the  purpose  of  distributed  use  and  integration  with 
other  NATO/PfP  national  centres. 

The  gateway  solution  connection  between  C31  and  M&S  applications  prototypically  implemented  for  the 
Royal  Army  of  the  Netherlands  as  presented  in  [P-09]  can  be  seen  as  a  state  of  the  art  implementation  of 
C31  and  M&S  interoperability.  Although  common  infrastructures  are  envisioned  for  future  applications, 
interfaces  like  this  are  likely  to  be  the  rule  for  the  mid  term  future.  Similar  approaches  can  be  found  in 
various  national  examples  (see,  e.g.  [P-01]). 

It  should  be  pointed  out,  that  some  papers,  e.g.  [P-05,  P-09,  P-11],  are  dealing  with  the  potential  and 
ongoing  research  to  use  M&S  within  C31  systems  to  support  the  operational  decision  making  process  by 
applying  M&S  in  the  harmonized  suite  of  decision  support  systems.  Although  the  technical  challenge  to 
couple  C31  and  M&S  is  at  least  comparable  to  CAX,  the  requirements  to  be  fulfilled  by  the  M&S  systems 
to  support  real  operations  are  higher  than  for  the  application  within  training  and  education.  Credibility  of 
the  M&S  application  and  the  necessary  Verification  and  Validation  was  mentioned  in  the  discussions. 


INTEROPERABILITY  AND  DATA  STANDARDS 

In  the  discussions  following  various  presentations  on  interoperability  and  data  standards  it  was  pointed  out 
-  in  particular  from  the  academia  present  at  the  conference  -  that  data  exchange  is  necessary  for  C3I  and 
M&S  interoperability,  but  not  sufficient.  While  actual  standards  and  solutions  are  targeting  the 
implementation  level,  meaningful  interoperability  can  only  be  reached  on  the  modelling  level.  Actually, 
the  modelling  level  is  aligned  by  additional  procedures  to  follow  when  setting  up  federations  (as 
documented  in  the  Federation  Development  and  Execution  Process).  The  results  of  the  Simulation 
Interoperability  Standards  Organization  (SISO;  see  http://www.sisostds.org)  Study  Groups  are  supporting 
this  perception  [P-01].  New  standards  will  take  this  into  account,  such  as  the  Model  Driven  Architecture 
(MDA)  approach  of  the  Object  Management  Group  (OMG;  see  http://www.omg.org/mda).  In  the  section 
on  Future  Projects,  some  additional  information  concerning  the  applicability  of  these  new  standards  for 
NATO  M&S,  C3I,  and  C3I  and  M&S  interoperability  will  be  given. 

The  use  of  a  common  source  to  initialise  C3I  and  M&S  systems  is  one  of  the  most  obvious  uses  of 
common  data  standards.  The  second  immediately  obvious  use  is  the  sharing  of  information  by  using 
standardized  shared  data  elements.  Both  ideas  were  part  of  the  presentation  of  the  French  project 
ESTHER  [P-05].  For  the  initialisation,  XML  documents  are  created  from  the  ESTHER  data  source.  All 
participating  systems  and  components  are  able  to  map  the  XML  tagged  information  to  their  own 
presentation.  The  NATO  Reference  Database  presented  as  part  of  [P-02]  is  also  pointing  into  this 
direction.  The  same  approach  is  furthermore  used  for  the  German  Integrated  Army  Modelling  and 
Simulation  Data  Network  [P-08],  It  is  of  special  interest  that  the  NATO  Command  and  Control 
Information  Exchange  Data  Model  (C2IEDM,  NATO  Standard  ADatP-32)  was  enhanced  and  extended 
for  this  purpose  following  the  C2IEDM  extension  rules.  Generally,  data  interoperability  is  seen  as  a 
necessary  precondition  for  C3I  and  M&S  interoperability,  and  using  an  established  C3I  originated  data 
model  as  the  generic  hub  will  support  the  vision  of  C3I  and  M&S  interoperability  more  efficiently  than  it 
would  be  the  case  using  a  proprietary  or  newly  developed  data  model. 

The  Extensible  Mark-up  Language  (XML)  is  used  in  various  applications  with  great  success,  examples 
given  during  this  conference  can  be  found  in  [P-05,  P-08,  P-1 1].  However,  the  use  of  XML  doesn’t 
ensure  interoperability  per  se,  but  that  management  of  the  tags  used  for  the  exchange  of  information  is 
mandatory.  The  actual  namespace  management  of  the  C3I  community  therefore  must  be  reflected,  or  - 
where  possible  -  used  for  XML  based  data  information  share.  Potential  future  mark-up  languages,  such  as 
the  recently  introduced  Simulation  Reference  Mark-up  Language  (SRML;  see  www.w3.org/TR/SRML/), 
will  support  interoperability.  However,  without  being  accompanied  by  aligned  management  processes, 
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meaningful  interoperability  cannot  be  reached. 

HLA  is  not  the  only  method  of  choice  to  reach  interoperability  between  C31  and  M&S.  The  use  of  open 
and  commercially  supported  interoperability  enablers  was  presented  in  various  papers.  In  particular,  the 
use  of  Internet  technologies  [P-10],  Extensible  Mark-up  Language  (XML)  [P-12],  Unified  Modelling 
Language  (UML)  [P-14]  and  the  Common  Object  Request  Broker  Architecture  (CORBA)  [P-13]  should 
be  mentioned.  The  Model  Driven  Architecture  (MDA)  of  the  Object  Management  Group  (OMG)  is 
supporting  all  these  solutions  and  seems  to  have  the  potential  to  become  the  overarching  coordinating 
approach.  These  approaches  are  not  mutual  exclusive  but  complementary  with  huge  overlaps.  A  common 
overarching  principle,  such  as  the  MDA,  enables  the  community  furthermore  to  generalize  enhancements 
and  extension,  such  as  that  recommended  for  UML  in  [P-14]:  contrarily  to  having  this  valuable  work 
available  only  in  UML,  the  approach  to  align  the  various  techniques  using  the  MDA  allows  the  reflection 
of  the  results  in  neighboured  methods  as  well.  As  MDA  is  applied  in  C3I  development,  there  seems  to  be 
a  good  applicability  of  the  MDA  to  C31  and  M&S  interoperability  issues.  Furthermore,  the  migration  to 
web  enabled  solutions  is  supported  by  the  MDA,  so  that  new  developments  in  the  C3I  community,  in 
particular  the  Global  Information  Grid  (GIG,  see  U.S.  DoD  Directive  8100.1),  can  be  coped  with. 

Modelling  issues  dealt  with  in  this  conference  will  support  the  identification  of  necessary  levels  of 
interoperability  as  well  as  critical  connections  between  C3I  and  M&S.  In  the  mid  term  future,  approaches 
such  as  presented  in  [P-15,  P-16]  will  enable  the  evaluation  of  C3I  architectures  as  well  as  C3I  and  M&S 
architecture  before  these  are  established  and  will  support  the  definition  of  necessary  information  exchange 
requirements  as  well  as  process  harmonization  requirements.  In  the  long  term,  better  and  even  automatic 
support  may  become  an  option  if  software  agents  can  make  use  of  these  architecture  models  effectively 
and  efficiently.  To  this  end,  however,  meta-data  of  the  models  of  the  C3I  and  M&S  architecture  are 
needed  describing  the  reliability  of  the  data,  constraints  and  assumptions  of  the  model,  pedigree  of  data 
and  models,  and  the  other  meta-data  as  exemplarily  specified  in  the  NATO  Code  of  Best  Practise  for 
Command  and  Control  Assessment  (see  http://www.dodccrp.org/nato_supp/nato.htm).  Examples  helping 
to  answer  the  question  why  such  data  and  meta-data  are  so  important  are  given  in  [P-17]  dealing  with 
essential  precondition  for  coupling  model  based  information  systems.  Furthermore,  the  paper  shows  that 
interoperability  of  models  is  often  a  matter  of  the  alignment  of  the  conceptual  models,  not  the 
implementation  level.  The  fact  that  two  models  can  be  linked  to  exchange  “bits  and  bytes”  doesn’t  imply 
that  the  resulting  federation  operationally  makes  sense.  For  meaningful  interoperability,  the  conceptual 
models  must  be  mapped  to  each  other  as  well.  The  domain  of  “composability”  dealt  with  under  the 
umbrella  of  SISO  and  DMSO  also  contributed  to  the  discussion.  Meaningful  interoperability  on  the 
implementation  level  requires  composable  models  on  the  conceptual  level. 


FUTURE  PROJECTS 

The  use  of  new  standards  and  their  applicability  to  NATO/PfP  M&S,  C3I,  and  C3I  and  M&S 
interoperability  was  the  topic  of  various  discussions.  Explicitly  mentioned  were  the  Model  Driven 
Architecture  (MDA)  developed  by  the  Object  Management  Group,  Web  Services,  and  the  Extensible 
M&S  Framework  (XMSF).  As  previously  mentioned,  the  actual  M&S  standards  Distributed  Interactive 
Simulation  (DIS)  and  High  Level  Architecture  (HLA)  are  targeting  the  implementation  level  while 
meaningful  interoperability  requires  alignment  on  the  conceptual  level.  The  various  levels  of  system 
interoperability  are  defined  in  [P-08]  and  the  definition  is  supported  by  ongoing  work  within  academia  and 
industry.  A  common  ontology  is  the  objective  of  various  projects  initiated  by  several  nations;  examples 
are  given  in  [P-01,  P-05,  P-08,  P-09].  Data  Repositories  and  M&S  Repositories,  as  mentioned  in  [P-02,  P- 
12,  P-19],  are  a  step  into  the  right  direction,  but  to  establish  an  aligned  approach;  the  establishment  of  a 
coordination  organization  is  necessary.  To  reach  this  goal,  [P-09]  recommends  the  development  of  a 
“Master  Plan”  to  align  the  software  architectures  and  the  data/object  models  supporting  NATO  C3I  and 
M&S  interoperability.  The  analyses  of  national  contributions  and  conducting  additional  feasibility  studies 


RTO  MP-MSG-022 


TER -5 


Technical  Evaluation  Report  MSG-022/SY-003 


ORGANIZATION 


under  aegis  of  the  NMSG  are  valid  options  for  future  projects. 

Additionally  to  this  technical  research  and  development,  action  on  the  bureaucratic  side  is  also  needed, 
e.g.,  capability  packages  and  requirement  analysis  for  actual  C31  solutions  and  possibly  future  STANAG 
development  must  be  addressed  concerning  C3I  and  M&S  interoperability.  Examples  how  this  is  done  in 
the  domain  of  Tactical  Missile  Defence  are  given  in  [P-02],  In  particular  the  Missile  Defence  Testbed 
Vision  is  a  valuable  example  of  common  requirement  derivation  and  analyses.  An  example  of  how  this 
was  done  for  STANAG  development  for  low-level  tactical  data  exchange  is  given  in  [P-12].  This  paper 
also  comprises  a  list  of  challenges  to  achieving  low  level  tactical  data  exchange,  which  can  easily  be 
generalized  for  C3I  and  M&S  interoperability.  Additionally,  recommendations  for  other  actions 
concerning  the  alignment  of  NC3TA  and  M&S  activities  and  the  use  of  the  S1SO  C41SR/Sim  Technical 
Reference  Model  within  the  NATO  standard  are  given  in  [P-1 8], 

One  key  enabler  of  new  infrastructures  is  the  existence  of  migration  concepts  for  legacy  solutions.  The 
ESTHER  project  of  the  French  Armed  Forces  [P-05]  shows  one  possible  way  to  integrate  Live,  Virtual, 
and  Constructive  C31  and  M&S  systems  using  common  standards  for  new  component  development  as 
well  as  wrapping  and  interfacing  legacy  systems.  Although  the  discussions  showed  that  there  are 
alternatives,  the  example  given  in  this  paper  is  state  of  the  art  and  can  serve  as  a  general  example. 

Although  not  directly  connected  to  the  challenge  of  C31  and  M&S  interoperability,  the  Training  and 
Education  Enhancement  Programme  (TEEP)  [P-03]  will  influence  the  future  development.  TEEP 
comprises  -  among  other  valuable  issues  -  interoperability  challenges  to  support  primarily  Partnership- 
for-Peace  (PfP)  efforts.  Objective  is  the  establishment  of  a  multinational  learning  environment  in  support 
of  interoperability  between  allies  and  partners,  including  various  CAX,  and  integrating  Advanced 
Distributed  Learning  (ADL)  and  Simulation.  In  support  of  this,  SACLANT/ACT  has  been  established  as 
the  single  focus  to  organize  and  coordinate  NATO/PfP  efforts  and  harmonise  it  with  national  efforts.  In 
which  way  this  will  influence  future  developments  is  open,  but  without  doubt  the  alignment  of  necessary 
participating  standards  -  such  as  the  High  Level  Architecture  (HLA),  the  Synthetic  Environment  Data 
Representation  and  Interchange  Specification  (SEDRIS),  and  the  Shareable  Content  Object  Reference 
Model  (SCORM)  -  will  be  a  main  issue. 

The  use  of  the  Internet  for  future  Advanced  Distributed  Simulation  Systems  solutions  was  the  core  idea 
presented  in  [P-10],  focussing  on  Peer-to-Peer  (P2P)  applications.  The  NetSim  project  of  the  Swedish 
Defence  Research  Agency  is  analysing  the  usability  of  HLA  standards  in  this  new  environment.  In  the 
United  States,  the  Extensible  M&S  Framework  (XMSF,  see  http://www.movesinstitute.org/xmsf)  group  is 
doing  related  similar  research.  Leading  experts  see  “M&S  as  the  next  killer  application  on  the  Web”  (as 
stated  by  Dr.  Anita  Jones  on  6.  September  2002  during  the  XMSF  Symposium  at  George  Mason 
University,  Fairfax,  Virginia,  U.S.A.).  Future  projects  are  likely  to  make  use  of  these  technologies.  This 
vision  is  supported  by  the  ideas  comprised  in  [P-19],  presenting  an  overview  of  the  European  Co- 
Operation  for  the  Long-term  in  Defence  (EUCLID)  RTP  11.13.  The  products  and  results  are  published  on 
http://www.euclidl  1 13.com.  An  analysis  of  the  usability  of  their  results  in  the  domain  of  NATO  C31  and 
M&S  interoperability  may  be  valuable.  As  EUCLID  RTP  11.13  is  tightly  related  to  web  based 
distribution  of  M&S  application  based  on  the  concepts  of  the  High  Level  Architecture  (but  not  necessarily 
limited  to  its  implementation),  this  should  be  technically  feasible  with  minimal  effort;  however,  the 
contractual  issue  may  become  an  obstacle. 


SUMMARY  AND  RECOMMENDATIONS 

Interoperability  of  C3I  and  M&S  systems  is  a  necessary  requirement  for  effective  and  efficient  support  of 
future  military  operations,  including  procurement,  acquisition,  test  and  evaluation,  training,  and 
application  of  necessary  functionality  within  the  ongoing  operation.  In  order  to  be  able  to  support  this 
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task,  a  close  understanding  and  knowledge  of  the  software  architecture,  the  communications  protocols, 
possible  interfaces,  data  and  object  models,  and  the  management  procedures  used  on  the  C31  and  M&S 
side  is  mandatory. 

The  majority  of  the  actual  solutions  are  interface  driven  to  link  stove-piped  developed  legacy  systems. 
The  use  of  common  reference  models  facilitating  the  necessary  data  alignment  and  information  exchange 
is  a  first  step  to  broader  and  reusable  solutions.  Newer  systems  with  configurable  interfaces  making  use 
of  these  technical  potentials  are  pointing  to  the  next  set  of  solutions. 

Although  the  number  of  engineering  solutions  of  linking  C31  and  M&S  systems  is  relatively  high,  the 
amount  of  “documented  lesson  learned”  is  relatively  small.  Most  solutions  are  ad-hoc  solutions,  not 
following  a  common  or  general  scheme.  In  order  to  establish  a  standard  way  -  which  increases  reusability 
and  collaboration  and  reduces  costs  and  risks  of  affected  projects  and  programmes  -  this  has  to  change. 
Documentation  of  applied  methods  and  procedures  must  be  captured  and  evaluated. 

Technical  Reference  Models  (TRM),  such  as  the  one  developed  by  the  Simulation  Interoperability 
Standards  Organization  (S1SO),  are  applicable  to  NATO  standards  and  will  facilitate  the  perception  of 
common  migration  paths  and  reusability  of  legacy  components  in  future  systems.  National  solutions  can 
be  mapped  to  these  TRMs  to  facilitate  joint  and  combined  C31  system  and  federation  planning. 

The  Command  and  Control  Information  Exchange  Data  Model  (C2IEDM),  which  is  the  NATO  Standard 
Allied  Data  Publication  No.  32  (ADatP-32)  and  the  data  model  of  choice  for  the  Multinational 
Interoperability  Programme  (MIP)  connecting  NATO’s  Command  and  Control  systems  and  the  basis  for 
various  national  C3I  systems,  is  successfully  used  for  data  alignment  in  various  national  projects  [P-08]. 
C2IEDM  was  not  only  applied  to  C3I  systems,  but  also  to  M&S  data  alignment.  As  the  NATO  Data 
Administration  Group  (NDAG)  is  already  using  the  C21EDM  for  data  management  for  C3I  systems,  the 
extension  to  M&S  systems  is  perceived  as  a  valuable  option. 

Future  interoperability  standards  will  depend  much  more  on  commercial  solutions  than  it  has  been  the 
case  in  the  past.  New  standards  as  the  next  generation  of  the  Unified  Modelling  Language  version  2.0 
(UML  2.0),  the  Extensible  Mark-up  Language  (XML),  web  services,  and  the  Model  Driven  Architecture 
(MDA)  are  applicable  to  C31  systems  as  well  as  to  M&S  systems.  They  support  actual  developments  to 
make  use  of  Internet  technologies  -  which  are  in  particular  observable  in  the  United  States  where  the 
definition  of  development  of  the  Global  Information  Grid  (GIG)  was  recently  initiated. 

Finally,  a  closer  relationship  between  the  NATO  M&S  Group  and  the  Simulation  Interoperability 
Standards  Organization  (SISO),  in  particular  the  observation,  and  where  appropriate,  active  participation 
in  Study  Groups  and  Product  Development  Groups,  is  likely  to  support  the  process  of  gaining  C3I  and 
M&S  interoperability  effectively.  A  formal  liaison  -  based  upon  the  initial  informal  relationship 
established  by  Dr.  Jean-Louis  Igarza,  first  Chief  Scientist  of  the  NMSG  -  will  ensure  that  the  NMSG  is 
aware  of  the  latest  developments  of  the  simulation  standardisation  world  and  can  influence  the  new 
standards  by  bringing  in  the  NMSG  requirements  as  early  as  possible,  i.e.,  before  the  standards  are 
established.  A  closer  relationship  with  EUCLID  projects  also  may  be  valuable. 

In  summary,  the  Conference  can  be  perceived  as  very  successful.  State  of  the  art  solutions  as  well  as  ideas 
and  requirements  for  necessary  future  research  and  development  were  presented  and  the  views  of  the 
armed  forces,  industry,  government,  and  academia  were  discussed.  The  papers  presented  during  the 
conference  provided  a  good  overview  of  what  has  been  done  in  NATO  and  NATO/PfP  nations,  what  is 
the  state  of  the  art,  and  the  next  steps. 
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I  am  Graham  Burrows  (Head  of  the  NATO  RTA  Modelling  and  Simulation  Co-ordination 
Office). 

I  have  the  honour  and  privilege  to  be  the  Chairman  of  the  Conference  Committee  of  this,  the 
4th  NATO  Modelling  and  Simulation  Group  Conference.  The  Theme  of  this  years 
Conference  is;  “C3I  and  Modelling  and  Simulation  Interoperability”  The  importance  of  M&S 
has  been  recognised  within  NATO  now  for  a  number  of  years  and  among  one  of  the  key 
applications  has  been  to  provide  support  for  military  operational  planning  and  in  exercising 
and  training.  But  key  to  this  support  has  been  the  linking  of  Models  and  Simulations  to  the 
many  and  diverse  C3I  systems  that  we  encounter  within  NATO  and  our  PfP  Partners  so  that 
we  may  indeed  adopt  the  paradigm  “  train  as  you  fight”  .  And  so  the  objectives  of  this 
Conference  are  to  contribute  to  a  better  understanding  of  and  an  improvement  in 
interoperability  between  M&S  and  C3I  systems.  1  am  sure  you  will  find  the  Conference 
interesting  and  stimulating  and  worthy  of  the  high  standard  and  reputation  that  this 
Conference  has  engendered.  Again,  this  year  the  Conference  has  attracted  a  high  number  of 
high  quality  papers  -  almost  twice  the  number  that  we  could  accommodate  in  the  time 
available.  This  has  presented  somewhat  of  a  challenge  to  the  Conference  Committee  -  but  I 
am  pleased  to  say  that  the  Committee,  as  always,  enjoys  a  few  challenges  and  this  they  took 
in  their  stride. 

I  would  like  to  thank  the  Conference  Committee  for  their  help  and  support.  Y ou  will  find  all 
their  names  listed  in  the  Programme  Announcement. 

1  will  briefly  ask  the  Conference  Session  Chairs  to  stand  up  so  that  the  individual  Presenters 
may  later  make  contact  with  their  Session  Chairs  -  provide  them  with  a  CV  and  also  make 
sure  their  slides  have  been  loaded  onto  the  main  computer.  So  - 

Colonel  Z.  Ipekkan;  Col.  M  Finnem;  Mr  Hans  Jense;  Mr  Andy  Fawkes;  and  Mr  Brian 
Witherden. 

These  gentlemen  will  also  be  very  firm  with  timekeeping,  and  I  have  issued  red  cards  to  be 
flashed  to  any  of  our  presenters  that  stray  over  their  allotted  time. 

I  would  also  like  to  introduce  Dr.  Andreas  TOLK.  Andreas  is  a  visiting  professor  at  the  USA 
Virginia  Modelling,  Analysis  and  Simulation  Centre.  He  has  been  very  active  in  M&S  for 
many  years  and  has  made  great  contributions  particularly  in  the  Command  and  Control 
Systems  field.  Andreas  has  agreed  to  perform  a  very  useful  function  at  our  Conference  that  of 
the  Technical  Evaluator.  He  will  provide  a  critique  of  each  of  the  papers,  the  conference 
overall  and  the  subsequent  discussion.  This  evaluation  will  be  included  in  the  Conference 
CD/Proceedings. 

Finally,  I  would  like  to  offer  my  sincere  and  grateful  thanks  to  our  Turkish  hosts  for  providing 
these  excellent  facilities,  and  their  superb  overall  support. 


j  RTO-MP-MSG-022:  C3I  &  Modelling  and  Simulation  Interoperability  -  Introduction 


Enjoy  the  Conference,  in  particular  the  Papers,  please  also  make  use  of  the  breaks  for  side 
discussions,  and  enjoy  Antalya.  You  are  here  in  a  beautiful  part  of  the  world  at  a  particularly 
attractive  autumn  period  - 1  hope  the  weather  will  be  kind  to  you. 
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Host  Nation  Welcome  Address 

(9  Oct  2003) 

Colonel  Z.  IPEKKAN 

Deputy  chief  of  Turkish  general  staff 
Scientific  Decision  Support  Center 
Host  Nation  Coordinator  and  NMSG  TU  Principal  Member 
06650  Bakanliklar,  Ankara,  Turkey 

Commanding  officer,  distinguished  representatives  of  NATO  and  PfP  nations,  good  morning. 

1  am  Colonel  Ziya  IPEKKAN,  Deputy  Chief  of  Turkish  General  Staff  Scientific  Decision  Support  Center. 

Firstly,  1  would  like  to  express  my  great  pleasure  for  hosting  you  today  and  tomorrow  in  this  beautiful  city 
of  Turkey  for  C31  and  M&S  Interoperability  symposium  2003.  Welcome  you  all  to  Antalya  ! 

It  is  a  great  pleasure  for  me  to  announce  to  you  that  we  are  very  proud  to  host  another  RTO  activity  during 
this  week,  a  Lecture  Series  on  Biological  and  Chemical  Warfare  in  Istanbul  which  is  one  of  the  unique 
cities  of  the  world. 

We  put  great  emphasis  on  activities  carried  out  by  NATO  RTO  Panels/Groups  and  make  use  of  every 
opportunity  to  take  active  roles  in  their  studies.  We  believe  that  hosting  such  activities  like  this 
symposium  and  the  lecture  series  in  Istanbul  is  one  of  the  most  prominent  indicators  of  our  resolution. 
Now,  1  would  like  to  give  you  some  information  on  this  beautiful  city  where  we  are  holding  this 
symposium. 

Before  it  came  under  the  Ottoman  sovereignty  that  founded  in  1299,  Antalya  region  was  controlled  by 
Hittites,  Lydians,  Persians,  Seljuks  and  Byzantines. 

Antalya  is  located  in  the  Mediterranean  region,  which  is  one  of  the  seven  regions  of  the  republic  of 
Turkey.  The  population  of  the  city  is  around  1,5  million.  Antalya  is  considered  to  be  the  touristic  capital 
of  Turkey  and  the  east  Mediterranean  with  its  all  year  long  sunny  skies,  unique  natural  beauties, 
magnificent  beaches  lapped  by  clear  blue  waters  and  historical  wealth.  This  city  is  located  on  such  a  rare 
geography  of  the  earth  that  it  is  possible  to  ski  and  swim  on  the  same  day. 

After  this  brief  information  on  Antalya  and  its  history,  1  would  like  to  touch  on  a  couple  of  points  about 
Turkish  armed  force’s  view  about  modelling  and  simulation  domain.  Brigadier  General  PEKAR  wall  give 
you  more  detailed  information  on  this  issue  shortly  after  this  presentation. 

Due  to  ever  increasing  complexity  of  the  operational  environment  and  shrinking  defense  budgets,  like 
every  other  nation,  Turkey  is  being  forced  to  act  wisely  in  all  of  its  activities.  Within  this  context,  the 
importance  and  usefulness  of  modelling  and  simulation  systems  has  been  well  comprehended  by  Turkish 
armed  forces  and  most  of  the  emphasis  has  been  put  on  acquiring  educated  personnel  and  developing 
suitable  platforms  for  enhancing  cooperation  among  Turkish  armed  forces,  universities  and  industry.  As  a 
consequence  of  these  efforts,  the  contribution  of  modelling  and  simulation  systems  to  training,  analyses 
and  acquisition  functional  areas  is  increasing  day  by  day. 

Finally,  once  again  1  would  like  to  express  our  pleasure  for  hosting  you  in  this  unique  city  for  the  NATO 
Modelling  and  Simulation  symposium  2003.  1  hope  we  experience  a  very  fruitful  two  days. 
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Good  morning  ladies  and  gentlemen, 

First  I  would  like  to  express  that  it  is  a  privilege  and  a  great  pleasure  for  us  to  host  this  symposium  and 
the  distinguished  community  of  NATO.  Welcome  to  you  all! 

As  the  Head  of  the  General  Staff  Scientific  Decision  Support  Center,  I  would  like  to  express  my 
personal  views  about: 

•  The  importance  and  application  areas  of  the  modeling  and  simulation  activities  for  the  Turkish 
armed  forces,  and 

•  How  to  improve  the  effectiveness  and  the  efficiency  in  modeling  and  simulation  activities, 
specifically  in  the  common  ground  of  NATO. 

Within  the  limits  of  the  defense  budget,  we  focus  our  efforts  to  fulfill  our  needs  for: 

•  Conducting  the  defense  planning  and  management  activities  while  keeping  pace  with  the 
rapid  developments  of  this  information  age, 

•  Training  our  military  personnel  to  have  the  ability  to  use  all  those  state-of-the-art  defense 
systems  efficiently  and  effectively,  and 

•  Preparing  the  forces  for  every  type  of  mission,  including  the  NATO  or  United  Nation’s  peace 
operations  in  different  crisis  regions  of  the  world,  which  the  Turkish  armed  forces  has  never  refrained 
from  participation. 

Due  to  environmental  and  financial  constraints,  the  activities  and  resources  required  to  fulfill  those 
needs  have  confronted  with  being  reduced.  These  conditions  have  required  the  intense  application  of 
study-analysis-decision  making  process  in  every  aspect  of  the  defense  planning  and  management 
activities. 

Since  field  experimentations  and  live  exercises  cause  environmental  pollution,  and  have  a  high  cost,  it 
becomes  necessary  to  lessen  the  number  of  practices,  and  to  look  for  different,  specifically  economic, 
ways  of  meeting  needs  for  experimentation  and  training. 

At  this  point,  modeling  and  simulation  systems  come  forward  as  a  rapid  and  economic  tool. 

In  this  respect,  we  believe  that  exploiting  the  modeling  and  simulation  systems  is  one  of  the  primary 
requirements  to  conduct  the  activities  effectively  for  concept  development,  determinating  capability 
gaps,  system  definition  to  meet  capability  lacks,  systems  acquisition,  personnel  /  unit  training, 
exercises,  and  operations  analyses  within  given  constraints. 

Consequently,  we  actively  participate  in  every  NATO  activities  related  with  modeling  and  simulation, 
while  enhancing  our  national  assets  and  capabilities  in  this  respect. 

Since  1996  when  the  NATO  modeling  and  simulation  group  was  established,  Turkish  armed  forces 
have  been  steering  the  capabilities  of  the  national  universities  and  the  defense  industry  to  contribute  to 
developing  alternative  solutions  to  problems  encountered  in  defense  matters. 

In  this  respect,  the  Turkish  armed  forces  modeling  and  simulation  seminar  held  nationwide  in  1998 
was  the  first  attempt  in  enhancing  national  modeling  and  simulation  capabilities. 

More  than  500  attendees  from  different  national  universities,  public  or  private  sector  foundations, 
research  centers,  and  coiporations  participated  in  that  seminar. 

During  13  parallel  sessions  of  the  seminar,  58  papers  were  presented,  17  corporations  made 
demonstrations,  modeling  and  simulation  national  policy,  existing  and  required  capabilities  were 
addressed. 
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As  a  consequence,  in  order  to  institutionalize  the  modeling  and  simulation  activities  related  with 
personnel  training,  the  war  gaming  and  simulation  center  was  founded  in  the  Turkish  armed  forces  war 
college  in  1998. 


In  this  center,  the  main  goal  is  to  provide  models  and  simulation  systems  as  a  tool  exploited  in 
personnel  education  and  training. 

In  1999,  we  founded  modeling  and  simulation  laboratories  in  the  Middle  East  Technical  University 
and  Istanbul  Technical  University. 

The  main  objectives  of  those  laboratories  are: 

•  To  make  fundamental  and  applied  research 

•  To  develop  models  and  simulation  systems  for  providing  solution  alternatives  to  the  common 
problems  of  different  services, 

•  To  combine  the  efforts  and  the  capabilities  of  industry,  university,  and  armed  forces, 

•  To  establish  organizational  knowledge-base,  and 

•  To  institutionalize  the  collaboration  activities. 

In  parallel  to  those  activities,  our  universities,  like  the  Middle  East  Technical  University,  have  recently 
founded  techno-cities  within  their  campus  areas.  In  those  techno-cities,  subject  matter  experts  and 
technical  professionals  from  different  scientific  /  engineering  disciplines  and  defense  industry  site  can 
find  the  opportunity  to  exchange  know-how  and  enhance  knowledge  in  development  programs. 

We  believe  that  those  techno-cities  can  provide  utilities  and  facilities  in  service  of  the  NATO 
modeling  and  simulation  community. 

In  2000,  we  established  the  scientific  decision  support  centers  and  units  in  the  main  headquarters  of 
the  services  and  the  general  staff  in  order  to  provide  decision  support  to  high  level  decision  makers, 
and  to  coordinate  modeling  and  simulation  activities  related  with  employment  and  infrastructure 
initiatives. 

In  accordance  with  the  decision  support  centers  and  units,  the  Turkish  armed  forces  modeling  and 
simulation  coordination  and  consultation  boards  were  established  in  order  to  coordinate  the  M&S 
efforts  from  the  joint  point  of  view. 

During  the  last  five  years,  postgraduate  studies  related  with  M&S  in  different  national  and 
international  universities  have  been  provided  to  more  than  100  personnel  and  those  personnel  were 
assigned  to  the  posts  in  accordance  with  their  academic  backgrounds. 

In  cooperation  with  Turkish  armed  forces,  the  Middle  East  technical  University  started  a  postgraduate 
program  specifically  in  modeling  and  simulation.  The  scholars  have  chance  to  make  their  researches 
and  thesis  studies  in  the  modeling  and  simulation  research  and  application  center  in  the  same  campus. 
We  believe  that  this  postgraduate  program  can  serve  for  the  needs  of  the  NATO  nations  as  well. 

There  are  also  defense  institutes  in  our  army,  navy,  and  air  force  academies  for  officers  to  make 
scientific,  fundamental  and  applied  research. 

Turkish  armed  forces  also  makes  contributions  to  the  efforts  of  NATO  studies,  analysis,  and 
simulation  panel.  Recently  there  were  two  working  groups  lead  by  Turkey  in  the  NATO  SAS  Panel. 
While  enhancing  the  modeling  and  simulation  capabilities  in  parallel  to  the  developments  in  M&S 
domain,  it  is  also  necessary  to  spend  effort  to  disseminate  those  capabilities  among  the  services  and 
personnel  in  the  application  domain. 

We  believe  that  the  accreditation,  verification  and  validation  activities  for  models,  simulation  systems, 
and  certification  of  data  used  in  M&S  applications  are  the  essential  driver  efforts  for  M&S  to  be 
accepted  and  exploited  by  the  M&S  user  communities  throughout  the  armed  forces.  Our  efforts  in  this 
respect  are  still  ongoing. 

Canada  and  Turkey  have  been  collaborating  in  the  M&S  through  the  NATO  fellowship  program, 
which  has  been  actively  used  for  at  least  15  years.  We  have  been  observing  that  these  kinds  of 
collaborations  also  serve  in  establishing  a  common  M&S  culture  and  in  exchanging  M&S  knowledge 
between  nations.  We  strongly  recommend  that  other  NATO  nations  participate  in  and  provide  NATO 
fellowship  programs  among  each  other. 
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We  also  believe  that  various  research  centers  in  NATO  countries  can  be  guided  by  the  NATO  MSG  to 
establish  cooperation  between  them  with  respect  to  the  needs  of  NATO.  We  consider  that  our 
establishments  are  ready  and  eager  to  take  place  in  such  collaboration. 

In  the  light  of  the  global  changes  and  developments,  the  theme  of  the  symposium,  which  is  “C3I  and 
Modeling  and  Simulation  Interoperability44,  has  a  particular  significance  among  all  others. 

Modeling  and  simulation  systems  used  in  redefining  new  threats,  which  has  been  uncertain  as  a 
consequence  of  9/11,  and  in  determining  new  operations  forms  against  that  new  threat,  should 
certainly  cover  command  and  control  matters  with  a  required  level  of  detail. 

Thus,  we  believe  that  the  interoperability  between  C3I  models  and  other  simulation  systems  is  one  of 
the  indispensable  requirements  for  new  system  developments. 

During  this  symposium,  four  different  papers  will  be  presented  by  Turkish  authors.  Those  papers  will 
address  the  findings  and  issues  that  come  out  from  development  and  research  projects  about  modeling 
and  simulation  of  operation  command  centers,  modeling  of  border  security  and  control  systems, 
graphical  interface  software  developments  for  war  games,  and  modeling  command  and  control.  Those 
four  development  and  research  projects  were  conducted  with  the  cooperation  of  industry,  university 
and  the  Turkish  armed  forces. 

It  is  certain  that  NATO  nations  will  have  a  chance  to  share  their  knowledge  and  experience  on  M&S 
during  this  symposium.  We  believe  that  this  invaluable  activity  will  provide  the  opportunity  to 
exchange  information  that  can  help  us  avoiding  duplication  of  efforts,  and  determining  the  issues  we 
should  focus  and  /  or  aggregate  our  efforts  on. 

For  organizing  this  invaluable  symposium,  I  would  like  to  thank  the  NATO  Modeling  and  Simulation 
Group,  which  carry  the  burden  and  the  responsibility  of  guidance  and  coordination  in  use  and 
enhancement  of  M&S  technologies  among  NATO  nations. 

Finally,  once  again  I  would  like  to  express  our  pleasure  for  being  the  host  nation  of  the  2003  NATO 
Modeling  and  Simulation  Symposium,  to  say  “welcome  you  all  in  Turkey”,  and  I  wish  you  all  have  a 
good  time  and  enjoy  your  stay  in  Antalya. 

Thank  you. 
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OVERVIEW 

The  Simulation  Interoperability  Standards  Organization  (SISO),  in  particular  the  Planning  and  Review 
Panel  (PRP)  on  Command,  Control,  Communications,  Computers,  and  Intelligence  (C4I),  deals 
intensively  with  the  topic  of  M&S  and  C3IInteroperability  over  the  recent  Simulation  Interoperability 
Workshops  (SIW)  which  are  taking  place  in  the  Spring  and  in  the  Fall  every  year  in  the  United  States. 
Since  2001,  a  European  SIW  also  occurs  every  summer  in  Europe  in  various  places. 

The  SISO  C4I  Forum  addresses  primarily  the  modelling  and  simulation  of  Command,  Control, 
Communications,  Computers,  and  Intelligence  (C4I)  systems  in  constructive,  virtual,  and  live 
environments,  the  coupling  of  real  C3Isystems  and  simulation  systems  for  computer  assisted  exercises 
(CAX),  and  support  for  operations.  Additional  focus:  Development  of  a  Command,  Control, 
Communications,  Computers,  Intelligence,  Surveillance,  and  Reconnaissance  (C4ISR)  Technical 
Reference  Model  (TRM),  a  common  framework  for  C4ISR  system-to-simulation  interoperability,  and 
relationships  among  international  C4ISR  architectures.  It  sponsored  two  study  groups,  namely  the  Study 
Group  on  “C4I  Study  Group”  (March  1999  -  September  2000)  and  the  Study  Group  on 
“ C4ISRJ Simulation  Technical  Reference  Model  Study  Group”  (March  2001  -  September  2002),  which 
results  and  related  underlying,  parallel,  and  future  papers  will  be  presented  within  this  paper.  The  second 
Study  Group  will  present  the  results  of  additional  work  during  the  SIW  in  Fall  2003,  among  others  in  form 
of  a  “C4ISR/Simulation  Interoperability  Source  Book,  ” 


1  INTRODUCTION 

The  Simulation  Interoperability  Standards  Organization  (SISO)  is  dedicated  to  the  promotion  of  modelling 
and  simulation  interoperability  and  reuse  for  the  benefit  of  diverse  M&S  communities,  including 
developers,  procurers,  and  users,  world-wide.  SISO  originated  over  ten  years  ago.  The  initial  conferences 
rapidly  on  general  simulation  interoperability  evolved  into  the  Distributed  Interactive  Simulation  (DIS) 
Workshops.  The  DIS  Workshops  transformed  in  1996  into  a  more  functional  organization  called  SISO 
participating  actively  in  the  standardization  efforts  related  to  the  High  Level  Architecture  (HLA).  Today, 
SISO  is  concerned  with  all  sorts  of  standard  development  and  application  facilitating  interoperability 
between  simulation  systems  as  well  as  between  simulation  systems  and  real  life  systems. 

SISO  actually  conducts  three  workshops  per  year,  called  the  Simulation  Interoperability  Workshops 
(SIW).  Two  SIW  are  conducted  in  the  United  States,  the  Spring  SIW  and  the  Fall  SIW.  In  addition,  one 
European  SIW  is  conducted  in  summer. 
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The  scope  of  the  Workshop  encompasses  a  broad  range  of  simulation  issues  and  communities,  including 
military  applications  as  well  as  other  government  and  non-government  applications.  Workshop 
participants  include  simulation  developers,  simulation  users,  and  operations  analysts,  from  various 
government,  industry,  and  academic  communities.  The  Workshop  focuses  on  issues  involving  distributed 
interoperable  and  composable  simulations,  reusable  components,  and  on  the  development  of  a  common 
process  model  for  designing,  composing,  executing,  and  analysing  the  results  of  simulations,  as  articulated 
in  the  High  Level  Architecture  (HLA)  for  Modelling  and  Simulation.  While  HLA  is  definitely  a 
cornerstone  of  SISO  and  SIW  activities,  the  actual  scope  is  broadening  and  new  technologies  supporting 
concepts  of  advanced  distributed  simulation  are  evaluated  increasingly. 

The  SIW  include  tutorials,  papers  on  state-of-the-art  experiences,  identification  and  discussion  of 
interoperability  issues,  and  presentation  of  proposed  solutions.  As  these  solutions  are  prototyped  and 
demonstrated,  they  become  candidates  for  possible  standards  within  relevant  simulation  communities. 
Various  workshop  forums  provide  opportunities  for  user  and  technical  communities  to  meet,  share  ideas 
and  experiences,  identify  ways  to  make  distributed  simulation  more  effective  and  efficient,  and  support  the 
development  of  appropriate  interoperability  standards.  Of  particular  interest  for  the  conference  on  “C3I 
and  M&S  Interoperability”  is  the  forum  on  “Command,  Control,  Communications,  Computers,  and 
Intelligence  (C4I).” 

The  C4I  forum  addresses  standards  to  ensure  interoperability  when  coupling  simulation  systems  and 
C3Isystems,  standards  to  ensure  composability  when  integrating  simulation  components  and 
C3Icomponents  into  a  common  framework,  and  standards  to  represent  C3Isystems  and  the  underlying 
infrastructure  within  simulation  applications.  Within  this  forum,  papers  are  presented  which  are  dealing 
with  architecture  and  data/object  model  alignment,  common  frameworks,  applicability  of  C3Istandards 
and  open  standards,  and  lessons  learned  from  applying  these  standards.  In  particular,  C3Isupports  the 
development  of  enhanced  operational  functionality  based  on  M&S,  and  especially  on  increasing  the 
efficiency  and  abilities  of  the  Warfighter  by  introducing  simulation  capabilities  within  operational 
systems. 

The  C4I  forum  sponsored  two  Study  Groups  dealing  with  interoperability  of  command  and  control 
systems  and  simulation  systems.  The  role  of  a  SISO  Study  Group  is  to  prepare  a  domain  for  future 
standardization.  To  this  end,  the  scope  of  the  future  standard  has  to  be  defined,  time  lines  for  perceived 
achievements  are  established,  literature  researches  are  done  and  evaluated,  related  SISO  papers  are 
analysed,  and  respective  reports  and  supporting  documentation  are  produced  and  disseminated.  When 
successful  and  advanced  enough,  a  Product  Development  Group  will  take  up  the  work  to  establish  a 
proposal  for  a  new  standard  to  enhance  interoperability  for  simulation  systems  and  live  systems  as 
envisioned  in  the  SISO  charter. 

The  first  Study  Group  dealing  with  the  general  problem  of  command  and  control  system  to  simulation 
system  interoperability  was  called  “C4I  Study  Group”  and  was  conducted  from  March  1999  to  September 
2000.  The  second  Study  Group  was  called  “C4ISR/Simulation  Technical  Reference  Model  Study  Group” 
and  started  in  March  2001.  The  final  report  of  this  second  group  was  delivers  in  September  2002; 
however,  it  was  also  perceived  that  much  more  work  needed  to  be  done  before  a  Product  Development 
Group  could  be  established.  Therefore,  the  Study  Group  members  decided  to  work  on  additional  follow- 
on  products  under  the  aegis  of  the  C4I  forum.  The  next  report  will  be  delivered  during  the  Fall  SIW  2003 
to  be  conducted  in  September  2003  in  Orlando,  Florida,  United  States. 

The  author  chaired  the  C4I  forum  of  SISO  during  this  period.  Furthermore,  he  contributed  actively  to  the 
resulting  reports.  He  also  published  several  papers  dealing  with  this  issue,  some  of  them  having  been 
awarded  by  SISO. 

However,  this  paper  gives  his  personal  view  on  the  problem  domain  and  the  achievements  of  the  resulting 
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reports  of  the  Study  Groups.  The  findings  in  these  papers  are  therefore  individual  interpretations,  and 
neither  do  they  reflect  the  official  view  of  the  Virginia  Modeling  Analysis  and  Simulation  Center,  nor  the 
view  of  the  SISO  or  any  sponsors  of  the  related  efforts. 


2  DEFINITION  OF  THE  UNDERFYING  PROBLEM 

The  NATO  Modelling  &  Simulation  Master  Plan  (NMSMP)  [1]  defines  various  domains  of  simulation 
system  applications,  which  implicitly  demand  the  integration  of  simulation  systems  into  command  and 
control  systems  or  vice  versa,  e.g.,  to  conduct  computer  assisted  exercises  (CAX)  and  to  deliver  simulation 
based  support  to  operations.  Interoperability  of  these  two  families  of  systems  is  furthermore  necessary  to 
reach  the  Objectives  and  Subobjectives  of  the  NMSP,  as  stated  in  table  1. 


Table  1:  Objectives  and  Subobjectives  in  the  NATO  Modelling  &  Simulation  Master  Plan 


Objective  1 

Objective  2 

Objective  3 

Objective  4 

Objective  5 

Establish  a 
Common 
Technical 
Framework 

Provide  Common 
Services  in  NATO 
M&S 

Develop 

Simulations 

Employ 

Simulations 

Incorporate 

Technical 

Advances 

1 . 1  Adopt  HLA 

2.1  Compile 

M&S 

Information 

3.1  Identify  & 
Prioritise 
Requirements 

4.1  Plan 

Employment 

5.1  Monitor 

M&S  related 
Advances 

1.2  Establish 

Data 

Interchange 

Standards 

2.2  Provide  M&S 
Education 

3.2  Identify 
Strategies 

4.2  Provide 
Resources 

5.2  Conduct 
Research  & 
Development 

2.3  Establish  a 
Simulation 
Resource 
Library 

3.3  Allocate 
Resources 

4.3  Provide 
Databases 

5.3  Share 

Information 

2.4  Establish  a 

Help  Desk 

3.4  Execute 

Strategy 

4.4  Operate 
Simulations 

5.4  Implement 
Advances 

3.5  Provide 
Feedback 

4.5  Conduct 

Impact 

Assessment 

As  stated  in  [2],  one  of  the  shortcomings  of  the  NMSG  is  that  he  is  not  connected,  aligned,  or  harmonized 
with  the  NATO  Consultation,  Command  and  Control  (C3)  Technical  Architecture  (NC3TA)  [3];  neither  is 
the  NMSG  integrated  into  the  NC3TA. 

In  other  words:  Both  communities  -  C3I  and  M&S  -  are  using  the  same  or  very  similar  information 
technology  (IT)  and  the  same  commercially  driven  solutions  for  underlying  operations,  such  as  filing, 
networking,  messaging,  databases,  etc.;  however,  the  applications  of  both  communities  have  been 
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developed  in  a  stove-piped  manner  without  knowledge  of  the  other  sides  efforts  (and  often  not  even  with 
the  knowledge  of  the  efforts  of  the  same  community).  Unfortunately,  as  the  discussions  with  the 
participants  in  the  Study  Groups  showed,  this  observation  is  true  all  over  the  world,  last  but  not  least  in 
leading  countries  of  NATO,  such  as  the  France,  Germany,  the  United  Kingdome,  and  the  United  States. 

The  result  is  generally  an  interface  driven  solution,  such  as  categorized  in  [4].  Most  of  these  interfaces  are 
based  on  ad-hoc  efforts,  leading  to  rigid  information  infrastructures,  double  efforts,  the  permanent 
reinvention  of  the  wheels,  and  systems  with  interfaces  as  much  as  potential  partners.  This  solution  is  not 
satisfying.  Consequently,  alternative  approaches  were  proposed  since  several  SIW.  They  can  be  divided 
into  three  broad  categories: 

-  The  first  group  is  primarily  focussed  on  the  coupling  of  command  and  control  systems  with 
simulation  systems  based  on  the  idea  of  standardized  interfaces,  or  at  least  common  reference 
models  to  be  used  for  the  development  of  these  interfaces. 

-  The  second  group  tries  to  reuse  more  or  less  already  established  and/or  standardized  components 
and  solutions  to  enhance  C3I-to-M&S  Interoperability.  These  components  are  primarily  found  in 
the  C3I  domain,  such  as  Common  Message  Providers,  or  data  models  used  for  automatic  database 
replication  mechanisms. 

-  The  third  group  is  interested  in  setting  up  a  common  infrastructure  for  military  IT  to  be  used  by 
the  C3I  community  as  well  as  the  military  M&S  community.  In  particular  the  use  of  common 
commercial  solutions,  open  standards,  or  even  open  sources  could  facilitate  this  objective,  which 
needs  to  comprise  migration  concepts  for  legacy  applications  in  order  to  become  a  viable  option. 

SISO  deals  with  all  three  aspects,  and  in  the  Study  Group  reports  and  among  the  additional  SIW  papers, 
candidates  of  all  three  categories  can  be  found.  To  decide  which  is  the  most  promising  solution  would  be 
premature,  although  the  author  definitely  prefers  the  option  of  a  common  infrastructure.  However,  to 
reach  this  long-term  goal,  working  interface  solutions  will  be  necessary  to  proof  the  feasibility  and 
demonstrate  the  operational  usefulness  are  necessary,  and  the  work  being  done  in  this  category  may  be 
reused  for  migration  solutions  later.  The  use  of  C3I  components  is  also  just  a  step  to  a  common 
infrastructure,  as  it  only  makes  sense  to  use  C3I  components  if  they  are  efficient  enough  to  use  them  in  the 
M&S  context,  i.e.,  if  it  makes  sense  to  reuse  them. 

To  summarize  the  underlying  problem  it  can  be  stated,  that  standards  are  needed  to  bridge  the  gap  between 
legacy  systems  as  well  as  standards  to  avoid  stovepipe  like  developed  systems  in  the  future.  In  addition, 
migration  procedures  are  necessary  to  transform  valuable  legacy  applications  for  future  use. 

While  the  final  report  of  the  “C4I  Study  Group”  (March  1999  -  September  2000)  [5]  framed  the  problem 
and  identified  valuable  approaches,  the  final  report  of  the  Study  Group  on  “C4ISR/Simulation  Technical 
Reference  Model  Study  Group”  (March  2001  -  September  2002)  [6]  started  to  focus  on  standardizable 
framework  concepts.  In  addition,  a  C4ISR/Sim  Technical  Reference  Model  Sourcebook  [7]  as  well  as  a 
User  Guide  to  the  C4ISR/Sim  Technical  Reference  Model  [8]  were  initiated  to  deliver  additional  guidance 
for  potential  users.  These  two  last  documents  will  be  presented  during  the  Fall  2003  SIW. 


3  THE  C4I  STUDY  GROUP 

In  order  to  assess  “where  we  are  and  where  we  need  to  go,”  SISO  charted  an  M&S-to-C4I  Interoperability 
Study  Group  to: 

-  Provide  background  and  current  information  on  C4ISR  and  simulation  interoperability  efforts; 
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-  Provide  a  standards-based  assessment  of  past  and  current  interoperability  efforts;  and 

-  Make  recommendations  on  how  the  SIW  C4I  Forum  should  proceed  with  standards  development 
activities. 

The  final  report  of  this  Study  Group  [5]  discusses  “where  we  have  been,”  “where  are  we  now,”  “where  we 
should  go,”  and  “how  do  we  get  there.”  While  the  authors  of  this  report  have  collated  submissions  and 
edited  this  report,  in  truth  it  is  the  result  of  more  than  a  dozen  direct  contributions  in  the  form  of  draft 
sections  and  the  indirect  contributions  of  the  more  than  one  hundred  subscribers  to  the  SG-C4I  reflector. 

The  main  reason  for  setting  up  a  study  group  was  user  requirement  driven,  i.e.,  derived  from  necessities  to 
support  preparing  and  conducting  future  military  operations.  Simulation  interfaces  to  Command,  Control, 
Communications,  Computers,  Intelligence,  Surveillance,  and  Reconnaissance  (C4ISR)  systems  are 
essential  to  support: 

-  Simulation  Based  Acquisition  (SBA); 

-  Development  of  Doctrine,  Tactics,  Techniques,  and  Procedures  (DTTP); 

-  “Train  as  you  fight,”  in  particular  Computer  Assisted  Exercises  (CAX); 

-  Embedded  Training  (both  individual  and  collective); 

-  Course  of  Action  Development  and  Analysis; 

-  Mission  Planning  and  Rehearsal;  and 

-  Execution  Monitoring. 

To  satisfy  the  Study  Groups  goals,  this  report  comprises: 

-  Background  and  current  information  on  C4ISR  and  Simulation  Interoperability  efforts; 

-  A  standards-based  assessment  of  past  and  current  interoperability  efforts;  and 

-  Recommendations  on  how  the  Simulation  Interoperability  Workshop  (SIW)  C4I  Forum  should 
proceed  with  M&S-to-C4I  interoperability  related  standards  development. 

3.1  Message  oriented  Approaches 

An  overview  of  previous  attempts  to  couple  M&S  and  C3I  systems  establishes  the  basis  for  the  assessment 
and  the  recommendations  in  the  final  report.  As  the  contributors  to  the  report  mainly  gained  their 
experience  in  the  United  States,  the  majority  of  the  examples  are  from  U.S.  systems.  However,  some 
examples  from  the  NATO  environment  are  given  as  well.  The  first  approaches  used  C3I  messages  to 
couple  command  and  control  and  simulation  systems.  Mainly  to  support  CAX,  simulation  systems  were 
used  to  create  tactically  meaningful  and  adequate  text  messages,  e.g.,  in  ADatP-3,  OTH  Gold  or  USMTF 
format.1  The  link  between  the  Tactical  Simulation  (TACSIM)  to  the  U.S.  Automated  Defence  Information 
Network  (AUTODIN)  message  system  in  support  of  the  Tactical  Exploitation  of  National  Capabilities 
(TENCAP)  program  in  1980  is  an  early  example  of  such  efforts.  Another  example  given  in  the  report  is 
the  link  of  TACSIM  to  the  Korea  Combat  Support  System  (KCSS)  and  the  Korea  Air  Intelligence  System 
(KAIS)  for  key  intelligence  message  traffic.  KCSS  and  KAIS  were  the  primary  C3I  systems  that 
supported  the  Air  Component  Command  (ACC)  of  the  Korean  Combined  Forces  Command  (CFC). 
During  this  same  event,  there  was  a  linkage  developed  and  implemented  between  the  Air  Warfare 
Simulation  (AWSIM)  and  Tactical  Receive  Equipment  (TRE)/Tactical  Related  Applications  (TRAP) 
systems.  From  TRAP,  the  information  was  fed  through  a  TENCAP  project  component  known  as  the  Air 
Defence  Systems  Integrator  (ADSI).  This  allowed  enemy  aircraft  tracking  data  to  be  input  to  the  air 
defence  cell  at  the  Control  and  Report  Centre  (CRC).  In  this  way,  there  was  established  a  direct  linkage  of 


1  ADatP  =  Allied  Data  Publication;  OTH  =  Over  the  Horizon;  USMTF  =  United  States  Message  Text  Format. 
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simulation  data  to  major  operations  and  intelligence  centres,  including  the  intelligence  I&W  centres, 
Electronic  Combat  Centre,  Control  and  Report  Centre,  and  Combat  Operations. 

Of  particular  interest  could  be  the  example  of  the  Warrior  Preparation  Centre  (WPC),  a  U.S.  facility  for 
Command  Post  Exercise  (CPX)  support  in  Germany.  In  1994,  the  WPC  built  a  two-way  interface  between 
AWSIM  to  the  Contingency  Theatre  Automated  Planning  System  (CTAPS).  The  objective  of  the  effort, 
known  as  Project  Real  Warrior  (PRW),  was  to  maintain  the  existing  simulation  to  C4ISR  interfaces, 
expanded  those  where  possible,  and  to  establish  a  database  link  from  the  CTAPS  to  AWSIM.  The 
primary  motivation  behind  this  effort  was  the  reduction  of  manpower  within  the  exercise  response  cells  by 
providing  an  automated  entry  of  the  Air  Tasking  Order  (ATO)  into  AWSIM.  Since  the  ATO  can  contain 
upwards  of  2000  missions  per  day,  this  offered  a  significant  reduction  in  manpower  requirements.  These 
systems  were  used  for  later  NATO  exercises  as  well  and  many  lessons  learned  were  derived  for  NATO 
efforts  in  the  CAX  area. 

These  early  efforts  influenced  the  development  of  the  Modular  Reconfigurable  C4ISR  Interface  (MRCI) 
[10],  which  attempted  to  develop  a  standardized  data  output  stream  from  a  simulation  to  C3I  systems  and 
to  incorporate  a  standardized  method  for  converting  C3I  system  inputs  to  the  simulations.  This  effort  was 
initially  supported  by  DMSO  and  later  by  the  Defence  Advanced  Research  Project  Agency  (DARPA). 
MRCI  was  demonstrated  during  the  Synthetic  Theatre  of  War  (STOW)  1998  experiment.  While  many 
aspects  of  the  MRCI  experiment  were  similar  to  earlier  efforts  in  C4ISR  to  simulation  interoperability, 
there  were  two  unique  features: 

-  The  attempt  to  develop  a  standard  interface  to  the  C4ISR  environment,  in  contrast  to  previous 
efforts,  which  in  general  created  unique  interfaces  to  each  C4ISR  system. 

-  The  attempt  to  develop  and  mature  a  technology  for  translating  command  and  control  directives 
(or  commands)  into  simulation  “orders.” 

For  the  second  feature,  a  tool  known  as  the  Command  and  Control  to  Simulation  Interface  Language 
(CCSIL)  was  developed.  However,  although  MRCI,  and  in  particular  CCSIL,  were  applied  several  times, 
they  never  became  widely  accepted  in  any  of  the  two  communities. 

Additional  information  on  more  U.S.  efforts,  NATO  efforts,  and  national  efforts  is  given  in  the  report  [5]. 
Furthermore,  the  Long  Term  Scientific  Study  on  CAX  [9]  conducted  on  behalf  of  the  NATO  Research 
and  Technology  Organization  (RTO)  Panel  on  Studies,  Analysis  and  Simulation  (SAS)  gives  some 
examples  as  well.  In  addition  to  the  CPX  level  efforts  described  here  in  some  detail,  there  have  been  a 
number  of  efforts  to  develop  these  interfaces  at  the  entity,  and  even  the  engineering  level,  which  are  not 
covered  in  this  overview.  Furthermore,  the  use  of  binary  messages,  such  as  Link-16  or  the  Tactical  Digital 
Information  Link  (TADIL)  family,  is  an  issue  not  further  dealt  with  in  this  paper,  but  you  can  find 
paragraphs  dealing  with  examples  in  the  final  report  of  the  Study  Group. 

The  main  idea  of  all  message  driven  efforts  is  the  use  of  the  same  messages  that  are  used  for  the 
information  exchange  between  command  and  control  system.  The  main  advantage  of  this  approach  is,  that 
the  command  and  control  systems  haven’t  to  be  changed.  The  main  disadvantage  is  that  the  information 
to  be  exchanged  between  C3I  and  M&S  is  limited  to  the  message  content,  and  simulation  issues  normally 
did  not  contribute  to  the  definition  of  these  information  exchange  requirements. 

3.2  High  Level  Architecture  driven  Approaches 

The  use  of  the  High  Level  Architecture  (HLA)  for  M&S  systems  is  a  central  point  in  the  United  States 
DoD  Modelling  &  Simulation  Master  Plan  [11]  as  well  as  in  the  NATO  Modelling  &  Simulation  Master 
Plan  [12].  In  late  1994  and  early  1995,  the  Defence  Modelling  and  Simulation  Office  (DMSO)  conducted 
a  baseline  assessment  of  all  DoD  M&S.  From  this  assessment,  DMSO  published  in  the  first  U.S.  DoD 
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M&S  Master  Plan  in  October  1995.  This  plan  established  the  HLA  as  a  central  component  of  the  DoD 
M&S  Technical  Framework. 

Taking  the  U.S.  DoD  M&S  Master  Plan  as  one  input,  in  November  1996,  NATO  began  to  develop  a 
NATO  M&S  Master  Plan.  The  Conference  of  National  Armaments  Directors  (CNAD)  established  a 
Steering  Group  on  NATO  Simulation  Policy  and  Applications  with  a  mandate  to  craft  an  Alliance 
approach  to  simulation  in  order  to  improve  Alliance  operations.  The  resulting  NATO  M&S  Master  Plan 
establishes  a  co-operative  approach  for  applying  advanced  simulation  techniques  to  aid  in  satisfying  the 
needs  of  the  NATO  Alliance  and  its  member  nations.  It  is  assumed  that  successful  execution  of  the  master 
plan  will  promote  the  aim  of  Alliance-wide  simulation  interoperability  and  reuse,  while  also  providing 
national  and  NATO  bodies  with  significant  modelling  and  simulation  interest,  with  the  necessary  latitude 
to  meet  their  specific  needs.  Again,  the  High  Level  Architecture  plays  a  central  role. 

Consequently,  C3I  to  M&S  approaches  used  the  concepts  introduced  by  the  HLA,  in  particular  the  idea  to 
use  standardized  Reference  Federation  Object  Models  (FOM).2  In  the  following,  some  examples  are  given 
that  were  used  by  the  Study  Group.  All  FOMs  are  included  in  the  library  that  have  been  developed  by  the 
Study  Group  and  can  be  downloaded  from  the  SISO  website. 

The  Prototype  C4I  FOM  is  the  result  of  a  U.S.  Army  requirement  to  develop  a  common  environment  to 
facilitate  the  use  of  constructive,  virtual,  and  live  simulations  in  the  evaluation  of  C3Isystems  in  the 
Research,  Development,  and  Acquisition  (RDA),  the  Advanced  Concepts  and  Requirements  (ACR),  and 
the  Training,  Exercises,  and  Military  Operations  (TEMO)  domains.  To  be  effective,  the  simulation 
environment  must  be  capable  of  interoperating  with  real  C3Isystems  in  a  manner  that  is  flexible, 
extensible,  and  promotes  re-use  of  software  components.  The  prototype  C4I  FOM  is  a  step  toward 
providing  this  capability  by  providing  a  standardized  representation  for  interoperability  that  can  be  applied 
to  a  variety  of  C3Isystems. 

The  Naval  Research  Laboratory  is  developing  a  C4ISR  FOM  for  DII  COE  based  C4ISR  systems  under  the 
sponsorship  of  DMSO  and  DISA.  The  C4I  Ambassador  software  provides  two-way  links  between  the 
embedded  RTI  and  the  DII  COE  Services,  databases  and  C4ISR  Mission  Applications.  It  interprets  the 
FOM  (parses  and  reformats  data  as  necessary)  and  manages  simulated  data  distribution  within  C4ISR. 
This  development  builds  on  the  technology  contained  within  the  recently  released  Global  Command  and 
Control  System  (GCCS)  Embedded  Training  Segments  for  inserting  training  data  into  operational  GCCS 
systems. 

The  Study  Report  also  includes  sections  on  additional  FOMs,  among  others  the  U.S.  Joint  Forces 
Command  J6  NETWARS  FOM,  and  shows  potential  for  alignment.  The  principals,  however,  are  the 
same  among  these  approaches. 

The  main  idea  of  these  FOM  driven  approaches  is  to  capture  the  aligned  information  exchange 
requirements  using  the  format  of  the  High  Level  Architecture  Object  Model  Template.  The  main 
advantage  of  this  approach  is  that  HLA  compliant  systems  can  easily  use  this  information.  The  main 
disadvantage  is  that  the  command  and  control  systems’  interfaces  have  to  be  adapted  to  the  needs  of  HLA. 

3.3  The  Vision  of  the  C4I  Study  Group 

It  would  go  beyond  the  scope  of  the  overview  of  the  final  report  of  the  first  Study  Group  to  deal  with 
every  detail.  To  be  able  to  cope  with  the  vision,  however,  it  is  necessary  to  know  that  various  architecture 
concepts  were  evaluated  as  well.  In  particular  their  contributions  to  interoperability  of  C3I  and  M&S  were 


2 

“  It  is  assumed  that  the  reader  is  familiar  with  the  High  Level  Architecture;  therefore,  the  concepts  are  not  introduced  in  this 
paper. 
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an  issue.  To  the  evaluated  architectural  concepts  belong  the  High  Level  Architecture  (HLA),  the  Joint 
Technical  Architecture  (JTA),  the  U.S.  Defence  Information  System  Agency  (DISA)  defined  Common 
Operational  Environment  (COE),  and  the  NATO  C3  Technical  Architecture  (NC3TA).  Furthermore, 
various  existing  federations  are  described  in  the  final  report  to  complete  the  state  of  the  art  section.  Based 
on  the  findings,  the  in  the  following  paragraphs  summarized  vision  was  formulated. 


“Where  we  are  now  and  where  we  need  to  go.  ” 

2001  2010 


NEAR  TERM 


MID  TERM 


FAR  TERM 


Message  Based 
Black  Box  Link 
Custom  Point  to  Point) 
Limited  2-Way  Feed 
Sims  Initialize  C4I 
Sims  Update  C4I 


.Common  Databases 

•  Implicit  Interoperability 
.Full  2-Way  Exchange 

•  Internal  “Black  Box” 

.Plug  and  Play  L/V/C  &  C4I 


Figure  1 :  Vision  for  the  Way  ahead  (C4I  Study  Group,  2000) 


The  roadmap  for  improving  the  interoperability  between  simulations  and  C3Isystems  is  shown  in  Figure  1. 
For  the  near  term,  the  vision  depicts  the  currently  predominant  architectures  in  use  for  M&S-to-C3I 
interfaces.  Such  interfaces  are  mostly  custom  “point-to-point”  links  that  are  often  “black  box”  in  nature. 
Simulation  control  is  basically  one-way,  with  the  simulations  initialising  the  real  C4ISR  system  databases. 
In  the  mid  term,  it  is  expected  to  see  the  HLA  linking  constructive  and  virtual  simulations  on  the 
simulation  side  and,  on  the  “real”  side,  the  HLA,  via  common  components  found  in  C3I  systems  (e.g., 
components  of  the  U.S./NATO  Common  Operational  Enviromnent,  such  as  common  message  processors) 
also  allowing  C3I  systems  to  exchange  both  data  and  messages  with  simulations.  Simulation  initialisation 
will  be  two-way,  with  real  system  databases  providing  information  to  the  simulation  side.  Ultimately,  as 
shown  as  “Far  Term,”  a  have  full  two-way  linkages  via  common  databases  will  be  achieved,  thus 
achieving  a  higher  measure  of  interoperability.  The  vision  articulates  only  a  broad  vision  of  where  M&S- 
to-C3I  interoperability  needs  migrate  to  go  over  time.  The  Far  Term  is  not  an  end  state,  but  is  where  we 
could  be  in  2010  to  2012,  if  the  M&S  and  C4ISR  communities  articulate  their  joint  requirements  and 
develop  coordinated  architectures  and  standards. 

The  final  report  of  the  Study  Group  was  delivered  in  September  2000.  Many  of  the  mid-term  prediction 
became  reality,  such  is  the  growing  establishment  of  HLA  enriched  by  completing  open  standards, 
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although  the  overall  speed  of  the  process  has  been  overestimated,  as  we  are  overall  moving  slower  then 
expected  (or  maybe  hoped  for)  by  the  expert  group. 

4  THE  C4ISR/SIMULATION  TECHNICAL  REFERENCE  MODEL  STUDY 
GROUP 

The  “Report  Out  of  the  C4I  Study  Group”  [5]  presented  during  the  Fall  2000  SIW  called  for  a  standard 
frame  of  reference,  in  the  form  of  a  Command,  Control,  Communications,  Computer,  Intelligence, 
Surveillance,  and  Reconnaissance  (C4ISR)/SIM  Technical  Reference  Model  (TRM),  for  interoperability 
between  command  and  control  and  simulation  systems.  The  C4ISR/Sim  TRM  defines  methods  and  levels 
of  interoperability  of  systems  or  classes  of  systems.  The  report  also  cited  the  need  for  the  C4ISR/SIM 
TRM  to  include  a  broad  data  class,  Metadata;  and  requested  consideration  of  how  the  C4ISR/Sim  TRM 
would  relate  to  other  interoperability  models  in  a  follow-on  study  to  determine  the  desirability  of 
integrating  the  C4ISR/Sim  TRM  and  other  interoperability  models  such  as  the  DoD  Level  of  Information 
Systems  Interoperability  (LISI)  model,  the  NATO  interoperability  model,  and  other  national  and 
international  interoperability  models.  Accordingly,  the  C4I  Study  Group  (SG)  recommended  the 
formation  of  a  follow-on  C4ISR/Sim  TRM  SG  to  develop  a  C4ISR/Sim  TRM,  leveraging  existing  work; 
and  foster  development  of  that  TRM  into  a  formal  SISO  product.  The  resulting  C4ISR/Sim  TRM  Study 
Group  worked  together  for  22  months,  including  various  meetings  during  the  SIWs  as  well  as 
teleconferences  and  email  exchange.  The  Study  Group  consisted  of  international  experts  in  this  domain, 
however,  as  before  the  main  interest  lay  within  the  United  States.  The  final  report  [6]  was  presented 
during  the  Fall  2002  SIW  and  summarizes  the  efforts  of  the  C4ISR/Sim  TRM  SG,  and  provides 
recommendations  for  continued  development  of  the  TRM. 

The  C4ISR/Sim  TRM  SG  was  formed  to  create  a  standard  frame  of  reference  for  interoperability  between 
C4ISR  Systems  and  M&S  systems.  The  C4ISR/Sim  TRM  is  intended  to  be  used  to  describe  as  well  as 
categorize  the  interoperability  of  systems  or  classes  of  systems.  It  is  a  technical  model  that  can  be  used  to 
measure  the  level  of  interoperability  of  systems  or  classes  of  systems.  By  design,  the  TRM  facilitates 
analysis  of  requirements,  architecture,  design,  implementation,  and  testing  of  heterogeneous  systems.  In 
addition,  the  TRM  is  expected  to  support  improved  dialogue  among  users,  developers,  and  technicians  in 
the  C4ISR  community. 

The  Study  Group  realized,  that  a  unified  model  in  form  of  a  single  reference  model  might  be  difficult  to 
achieve.  Therefore,  another  approach  has  also  been  proposed  for  study  by  the  Study  Group:  Instead  of 
establishing  a  new  model,  existing  and  established  models  could  be  fused  as  complementing  views  on  the 
unifying  reference  architecture.  This  solution  is  coherent  with  solutions  proposed  in  the  U.S.  DoD  C4ISR 
Architecture  Framework  [13],  the  NATO  C3  System  Architecture  Framework  [14],  the  Joint  Technical 
Architecture  [15]  approach,  and  furthermore  reflects  the  interoperability  solutions  being  used  in  the 
commercial  branches  of  information  technology.  Although  the  final  report  of  the  second  Study  Group 
doesn’t  make  recommendations  how  the  framework  should  look  like  (this  is  done  in  the  follow-on  work, 
see  [7]),  it  identifies  the  relevant  reference  architectures  in  more  detail  -  and  adds  some  new  -  than  this 
was  the  case  in  the  initial  collection  used  in  the  report  of  the  first  Study  Group. 

4.1  Existing  C3I  to  M&S  Interoperability  Technical  Reference  Models 

The  first  TRM  to  be  mentioned  is  the  “House  Diagram,”  which  has  been  developed  by  Michael  Hieb  and 
Andreas  Tolk  to  facilitate  the  discussions  within  the  SIW  C4I  forum.  It  was  picked  up  by  various  authors 
and  proofed  to  be  a  valuable  although  simple  way  to  structure  the  various  interoperability  domains.  In 
summary,  the  “House  Diagram”  blueprints  the  complexity  of  interfacing  simulation  systems  and  command 
and  control  systems.  This  holistic  view  emphasizes  the  interdependency  of  five  major  factors  involved  in 
the  effort  to  secure  shared  solutions  for  C3I/M&S  interoperability:  Architectures  Alignment,  Common 


RTO-MP-MSG-022 


1  -9 


SISO  Study  Groups  on  C3I/M&S  Interoperability 


ORGANIZATION 


Data/Object  Models,  Common  Standards,  Alignment  Processes,  and  Reusable  Component  Interfaces. 


Figure  2:  The  "House  Slide"  on  Interoperability 


Architecture  Alignment  recognizes  the  fundamental  necessity  to  align  the  framework  architectures  for  both 
M&S  and  C3I  domains.  As  already  pointed  out  earlier,  the  U.S.  DoD  C4ISR  community  has  developed 
the  Defence  Information  Infrastructure  Common  Operating  Environment  (COE).  NATO  is  using  the 
NATO  Technical  Architecture  Model  (NC3TA),  including  the  NATO  COE.  The  M&S  community  has 
established  the  HLA.  These  constructs  establish  the  foundations  that  set  the  requirements  for  fundamental 
interoperability  between  components  of  these  two  domains.  The  architecture  alignment  needs  to  be  able 
to  resolve  differences  in  viewpoints  or  fundamental  representation  of  the  problem  space. 

Within  the  M&S  domain,  the  HLA  Federation  Object  Model  (FOM)  methodology  is  used  to  align  Data 
Models  and  Object  Models  among  M&S  federates.  While  this  methodology  works,  it  places  a  heavy 
burden  on  developers.  When  extending  beyond  the  M&S  domain  into  the  C3I  domain,  temporary 
(situational)  alignment  presents  additional  challenges:  synchronizing  development  cycles,  aligning  domain 
ontology,  and  coordinating  data  standards.  These  constraints  normally  resolve  into  the  need  for  a  data 
translation  layer  between  C3I  and  simulation  domains.  However,  this  gateway  strategy  can  exact  a  major 
performance  penalty.  If  systems  are  aligned  to  the  same  or  similar  object  model  or  data  model 
representations,  performance  increases  as  translation  penalties  and  FOM  alignment  burdens  decrease. 

Common  Standards  are  most  effective  when  they  are  part  of  the  system  design.  Integration  of  standards 
begins  with  the  framework  architecture  for  each  domain  and  extends  through  the  support  for  common 
objects  and  data  models.  To  this  end,  C3I  and  M&S  systems  should  be  designed  initially  for 
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Reusable  Component  Interfaces  sit  on  top,  and  therefore  rest  upon,  the  building  blocks  below.  However, 
when  compared  to  architectures,  models,  or  standards,  interfaces  have  been  a  hotbed  of  activity.  This 
apparent  paradox  stems  from  our  ability  to  partition  the  problem  space  at  the  interface  and  thus  provide 
short-term  solutions  for  quick  success.  However,  in  general  these  solutions  are  too  shallow,  one  has  to 
pay  and  pay  again  for  these  unique  interfaces  in  terms  of  costs,  time,  and  flexibility.  If  realignment  of  the 
underlying  structures  eliminates  basic  incompatibilities  between  the  systems  and  a  wealth  of  benefits 
ensues. 

Finally,  the  roof  of  the  house  diagram  envisions  Shared  Solutions  between  C3I  and  Simulations.  This 
aspiration  must  be  supported  by  all  of  the  underlying  blocks.  In  addition,  it  requires  that  the  systems  align 
or  translate  inherent  processes.  For  example,  terrain  alignment  and  object  placement  must  be  consistent 
between  components  in  both  domains. 

The  second  TRM  evaluated  in  the  final  report  of  the  C4ISR/Sim  TRM  Study  Group  is  the  C4ISR/Sim 
Technical  Reference  Model  for  Interoperability  as  introduced  by  Carr  and  Hieb  in  [16].  The  C4ISR/SIM 
Interoperability  TRM  identifies  data  types  exchanged  between  C3Iand  M&S  systems.  Systems  engineers 
identify  data  requirements  and  code  interfaces  to  handle  information  exchanges  between  C3I  and  M&S 
systems.  Generalizing  these  efforts,  one  can  document  and  classify  information  that  an  interface  must 
handle.  The  C4ISR/Sim  Technical  Reference  Model  for  Interoperability  builds  the  basis  for  the  follow-on 
efforts  dealt  with  in  the  next  section.3  Therefore,  we  will  not  discuss  this  TRM  at  this  point. 

The  third  TRM  has  been  introduced  by  Ressler,  Hieb,  and  Sudnikovich  [17].  They  describe  a  reference 
model  focused  on  the  information  exchange  activities  between  C4ISR  and  M&S  components.  They 
suggest  a  conceptual  reference  model  based  on  the  decomposition  of  processes  for  exchanging  data 
between  C4ISR  and  M&S  systems.  Their  Information  Exchange  Activity  Model  forms  a  central 
component  of  a  generalized  C4ISR/Sim  conceptual  reference  model.  This  Information  Exchange  Activity 
Model  captures  activities  essential  to  establishing  interoperability  between  domains. 

To  cope  with  the  aspects  of  architecture  alignment  as  proposed  in  the  “House  Slide,”  Furness,  Carr,  and 
Hieb  introduced  the  fourth  TRM,  the  General  Unified  Model  (GUM)  for  M&S  to  C3I  interoperability 
[18].  This  high  level  model  divides  both  architectures  of  the  M&S  and  C3I  families  into  four  categories 
providing  the  ability  to  accommodate  functions  present  in  any  representative  implementation.  A 
reasonable  set  of  the  common  functions  of  both  C4ISR  systems  and  M&S  systems  provide  the  starting 
point  for  the  GUM.  The  resulting  candidate  set  of  common  functions  comprises  User  Interfaces, 
Management  and  Execution,  Data,  and  Algorithms.  This  list  is  neither  complete  nor  exclusive,  but  helps 
to  structure  the  architectural  domains  that  have  to  be  interoperable  for  a  given  purpose. 

A  lot  of  work  being  presented  within  recent  SIW  are  relevant  to  this  effort  as  well  and  has  to  be  taken  into 
account  although  not  directly  connected  to  a  reference  model.  The  topics  of  meta  data,  meta  modelling 
and  the  problem  of  data  alignment  have  to  be  stressed  in  this  context.  The  new  role  of  data  engineering 
emerged  from  respective  findings.  Within  actual  solutions  of  C4ISR  and  M&S  system  coupling,  the 
system  designer  tasked  with  the  integration  has  to  know  what  data  is  located  where,  the  meaning  of  data 
and  its  context,  and  into  what  format  the  data  have  to  be  transformed  to  be  used  in  respective  distributed 
applications  within  the  overall  system.  Data  Engineering  is  coordination  the  efforts  of  the  sub-tasks  of 
data  administration,  data  management,  data  alignment,  and  data  transformation.  The  first  three  can  be 
standardized  and  used  in  a  general  manner.  Only  the  task  of  transforming  the  data  really  is  system 
dependent,  and  it  has  been  shown  that  even  for  this  task  a  general  solution  exists. 


3 

Furthermore,  Carr  presents  during  this  NATO  Symposium  his  recent  findings  and  recommendations  in  Paper  No.  18  within 
this  proceedings. 
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-  Data  Administration  is  the  process  of  managing  the  information  exchange  needs  that  exist  within 
a  group  of  systems,  including  the  documentation  of  the  source,  the  format,  context  of  validity,  and 
fidelity  and  credibility  of  the  data.  Data  Administration  therefore  is  part  of  the  overall  information 
management  process. 

-  Data  Management  is  planning,  organizing  and  managing  of  data  by  defining  and  using  rules, 
methods,  tools  and  respective  resources  to  identify,  clarify,  define  and  standardize  the  meaning  of 
data  as  of  their  relations. 

-  Data  Alignment  ensures  that  the  data  to  be  exchanged  exist  in  the  participating  systems  as  an 
information  entity  or  that  the  necessary  information  can  be  derived  from  the  data  available,  e.g., 
using  the  means  of  aggregation  or  disaggregation. 

-  Data  Transformation  is  the  technical  process  -  often  implemented  by  respective  algorithms  within 
the  gateways  and  interfaces  -  of  aggregation  and/or  disaggregation  of  the  information  entities  of 
the  embedding  systems  to  match  the  information  exchange  requirements  including  the  adjustment 
of  the  data  formats  as  needed. 

Most  actual  works  are  focusing  on  data  transformation,  i.e.,  the  programming  or  maintenance  of 
interfaces.  However,  if  such  efforts  are  not  accompanied  by  an  alignment  of  the  respective  management 
processes  for  data  administration,  management,  and  alignment,  the  result  is  in  the  best  case  a  temporary 
valid  solution  that  is  effective  until  the  next  update  of  one  of  the  participating  systems.  Consequently,  the 
managing  processes  of  the  participating  systems  must  at  least  be  harmonized.  In  the  ideal  case,  the 
program  managers  will  even  use  the  same  methods  and  supporting  tools  to  do  so  under  a  common, 
overarching  approach  as  already  proposed  by  the  House  Slide  in  an  earlier  section. 

4.2  Relevant  Reference  Models  from  C3I  and  Commercial  Information  Technology 

In  addition  to  the  existing  C3I  to  M&S  interoperability  TRM,  relevant  reference  models  not  only  from  the 
C3I  community,  but  also  from  the  commercial  IT  world  were  evaluated.  For  the  complete  evaluation,  the 
interested  reader  is  referred  to  the  final  report.  In  this  overview,  we  will  just  mention  the  models  and  deal 
with  the  two  that  played  a  central  role  in  the  Study  Group,  namely  the  Level  of  Information  Systems 
Interoperability  (LISI)  [19]  and  the  NC3TA  Model  of  Interoperability  (NMI)  [3]. 

The  LISI  model  provides  a  reasonable  framework  to  scope  the  needed  level  of  connectivity  in  the  domain 
of  technical  interoperability.  LISI  is  established  by  the  U.S.  DoD  C4SIR  Framework  Architecture  [13]. 
LISI  identifies  four  domains,  namely  Procedures  and  Policy,  Applications,  Infrastructure,  and  Data 
(PAID).  Every  one  of  the  PAID  domain  impacts  on  information  exchange,  in  other  words,  a  level  of 
interoperability  exists  within  each  of  the  PAID  domains.  The  resulting  technical  interoperability  is 
measured  in  five  categories: 

-  Level  0:  Isolated  (Manual)  -  Non-connected,  use  of  manual  gateways  (diskettes,  etc.) 

-  Level  1 :  Connected  (Peer-to-Peer)  -  Electronic  connection;  Separate  data  and  applications 

-  Level  2:  Functional  (Distributed)  -  Minimal  common  Functions;  Separate  data  and  applications 

-  Level  3:  Domain  (Integrated)  -  Shared  data;  “Separate”  applications 

-  Level  4:  Enterprise  (Universal)  -  Interactive  manipulation;  Shared  Data  and  applications 

Level  4  is  the  highest  level  of  technical  interoperability,  i.e.,  data  is  electronically  delivered  to  the 
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Warfighter  regardless  what  access  method  he  uses  (from  handheld  to  C3I  workstations)  and  from  where  he 
uses  this  device.  He  can  just  plug  into  the  infosphere  and  can  use  all  applications,  wherever  he  is  and 
wherever  the  applications  are. 
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Figure  3:  The  LISI  Model 


NATO  is  using  a  very  similar  model  to  LISI.  It  is  comprised  in  the  NATO  C3  Technical  Architecture 
(NC3TA)  [3].  The  NC3TA  describes  the  IT  architecture  to  be  used  as  a  basis  for  interoperable  NATO 
systems.  It  addresses  architectural  descriptions,  reference  models,  and  Off-The-Shelf  (OTS)-technologies. 
Furthermore,  the  NC3TA  integrates  technical  aspects  of  specific  architectures  or  frameworks  such  as  the 
NATO  Information  Security  Framework.  The  NC3TA  consists  of  five  volumes  dealing  with 
Management,  Architectural  Models  and  Description,  Base  Standards  and  Profiles,  NC3  Common 
Standards  Profiles  (CSP),  and  the  NC3  Common  Operating  Environment  (COE).  The  NC3TA  contains 
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five  technical  reference  models  of  interest  to  our  review  of  C4ISR/M&S  interoperability: 

-  The  NC3TA  Technical  Reference  Model  (NTRM)  provides  the  conceptual  framework  and 
common  vocabulary  for  addressing  interoperability  and  compatibility  among  NATO  information 
systems.  It  sets  a  foundation  for  all  NC3  technical  architectures. 

-  The  NATO  Common  Operating  Environment  (NCOE)  Component  Model  (NCM)  instantiates  the 
NTRM  and  models  the  NCOE  architecture.  In  turn,  the  NCOE  aspires  to  define  a  plug  and  play 
client/server  environment  [Volume  5]  to  increase  interoperability,  reusability,  portability,  and 
operational  capability  while  reducing  development  time,  technical  obsolescence,  training 
requirements,  and  life  cycle  cost. 

-  The  NATO-Common-Funded  (NCF)  Reference  Models  for  Functional  Configurations  (NFC) 
refines  the  NCM.  This  set  of  reference  models  provides  functional  configurations  as  building 
blocks  for  developing  the  functional  architecture  of  NCF  systems. 

-  The  NATO  Reference  Model  for  Open  Systems  Information  Interchange  (NOSI)  focuses  on 
communications  issues  not  covered  by  previous  models. 

-  The  NC3TA  Reference  Model  for  Interoperability  (NMI)  models  technical  interoperability  by 
leveraging  the  concept  of  degrees  of  interoperability.  Categories  of  elementary  services  form  a 
descriptive  basis  for  functional  interoperability  profiles. 

The  NC3TA  reference  model  for  interoperability  (NMI)  establishes  interoperability  degrees  and  sub¬ 
degrees.  Interoperability  degrees  define  a  maturity >  model  that  captures  interoperability  sophistication. 
Interoperability  sub-degrees  describe  a  capability  model  that  reflects  available  functionality.  These 
degrees  highlight  the  value  of  structuring  and  automating  exchange  and  interpretation  of  data  to  enhance 
operational  effectiveness.  The  NMI  provides  definitions  for  interoperability  degrees  and  sub-degrees  and 
presents  interoperability  profiles.  The  NMI  classifies  interoperability  at  four  levels. 

-  Degree  1 :  Unstructured  Data  Exchange 

This  level  involves  the  exchange  of  human-interpretable,  unstructured  data  such  as  the  free  text 
found  in  operational  estimates,  analysis,  and  papers.  Sub-degrees  are  Network  Connectivity, 
Basic  Document  Exchange,  and  Basic  Informal  Message  Exchange. 

-  Degree  2:  Structured  Data  Exchange 

This  level  involves  the  exchange  of  human-interpretable  structured  data  intended  for  manual 
and/or  automated  handling,  but  requires  manual  compilation,  receipt,  and/or  message  dispatch. 
Sub-degrees  are  Enhanced  Informal  Message  Exchange,  Enhanced  Document  Exchange,  Network 
Management,  Map  Overlays/Graphics  Exchange,  Directory  Services,  Web  Access,  Multi-Point 
Applications,  and  Data  Object  Exchange. 

-  Degree  3:  Seamless  Sharing  of  Data 

This  level  involves  automated  data  sharing  within  systems  based  on  a  common  exchange  model. 
Sub-degrees  are  Formal  Message  Exchange,  Common  Data  Exchange,  System  Management, 
Secure  Systems  Management,  Security  Management,  and  Real-time  Data  Exchange. 

-  Degree  4:  Seamless  Sharing  of  Information 

An  extension  of  degree  3,  this  level  establishes  universal  interpretation  of  information  through 
cooperative  data  processing.  Sub-degrees  are  Common  Information  Exchange,  and  Distributed 
Applications. 
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Unconnected  systems,  which  would  represent  the  interoperability  level  of  degree  zero,  are  not  mentioned 
in  the  NATO  C3  Technical  Architecture.  The  Seamless  Sharing  of  Information  (degree  3)  equals  the 
Universal  Interoperability  Level  (level  4)  of  Enterprise  Solutions  as  envisioned  in  LIST 

The  final  report  of  the  C4ISR/Sim  TRM  Study  Group  furthermore  deals  the  other  NC3TA  technical 
reference  models  and  their  applicability  as  well.  In  the  context  of  this  paper  it  may  be  worth  mentioning 
that  the  IEEE  POSIX  Open  System  Environment  (OSE)  Reference  Model  [20]  is  part  of  these  NATO 
TRM.  The  POSIX  model  is  the  basis  for  other  TRM  as  well,  e.g.,  the  U.S.  DoD  and  U.S.  Federal 
Technical  Reference  Models. 

The  final  report  of  the  C4ISR/Sim  TRM  Study  Group  ends  with  the  recommendation  to  enhance  the 
C4ISR/Sim  Technical  Reference  Model  as  proposed  in  [16].  In  addition,  a  C4ISR/Sim  TRM  Sourcebook 
and  a  user  guide  are  recommended.  The  SISO  committees  accepted  all  three  recommendations. 
Therefore,  a  third  Study  Group  was  launched  in  Fall  2002. 


5  THE  C4ISR/SIM  TECHNICAL  REFERENCE  MODEL  SOURCEBOOK  AND 
THE  USER  GUIDE  TO  THE  C4ISR/SIM  TECHNICAL  REFERENCE 
MODEL 

While  the  previous  two  sections  deal  with  conducted  Study  Groups,  this  section  is  dealing  with  the 
ongoing  efforts  of  the  third  Study  Group  of  SISO  dealing  with  the  issues  of  C3I  to  M&S  interoperability. 
The  results  will  be  presented  during  the  SIW  Fall  2003.  However,  as  the  author  is  member  of  the  editor 
and  contributor  committee  for  the  reports  of  this  third  Study  Group,  preliminary  results  of  the  respective 
drafts  could  be  comprised  in  this  paper  already.  However,  it  is  strongly  recommended  to  look  at  the 
sourcebook  [7]  and  the  user  guide  [8]  as  soon  as  they  are  published. 

Two  of  the  efforts  described  in  the  Sourcebook  [7]  will  be  described  in  this  overview.  The  first  is  the  first 
draft  of  the  C4ISR/Sim  TRM  Framework;  the  second  is  the  C4ISR/Sim  TRM  in  the  actual  state  as  derived 
starting  with  the  model  as  introduced  by  Carr  and  Hieb  in  [16]. 

It  already  has  been  pointed  out  that  the  technical  solutions  being  already  available  are  doomed  to  failure  if 
not  accompanied  by  respective  organizational  and  procedural  alignments.  New  evolving  standards  within 
the  IT  world  -  such  as  the  Extensible  Mark-up  Language  (XML)  -  are  often  perceived  to  deliver  long 
searched  solutions,  but  in  general  they  only  affect  one  factor  of  the  “house  slide”  as  depicted  in  the  last 
section.  Without  the  emphasized  holistic  view  the  vision  of  one  common  command  and  control  systems 
based  on  heterogeneous  information  technology  implementing  the  required  functionality  of  command  and 
control  as  well  as  Operations  Research  -  including  modelling  and  simulation  -  will  remain  a  pure  wish. 
In  this  sense,  the  various  TRM  presented  in  the  second  report  as  well  as  in  the  last  section  of  this  paper  are 
dealing  only  with  special  aspects  of  the  challenge  to  reach  interoperable  and  shared  solutions.  In  general, 
all  these  views  and  models  are  needed  to  support  “the  big  picture.” 

The  C4ISR/Sim  TRM  Study  Group  first  dealt  with  this  issue  in  Spring  2002  and  recommended  as  a  long¬ 
term  goal  to  establish  a  framework  comprising  various  complementary  C4ISR/SIM  TRM  views,  following 
the  example  of  the  U.S.  DoD  C4ISR  Architecture  Framework  [13]  and/or  the  NATO  C3  System 
Architecture  Framework  [14],  both  of  which  using  operational,  system,  and  technical  views  to  describe  the 
command  and  control  architecture  in  total.  Figure  4  shows  the  proposed  structure  without  claiming 
completeness.  The  various  candidates  are  those  mentioned  in  the  TRM  sections  of  the  previous  two 
reports. 

The  four  recommended  views  are  the  Functions  and  Data  View,  which  focuses  on  the  data  exchanged  and 
functions  provided  via  the  interfaces  of  the  M&S  and  C3I  systems,  the  Software  Component  View,  which 
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deals  with  the  components  to  be  addresses  or  reused  within  the  participating  M&S  and  C3I  systems,  the  IT 
Systems  View,  which  deals  with  the  information  technology  aspects  not  being  special  to  M&S  or  C3I 
systems  but  still  influencing  their  way  how  to  interoperate,  and  finally  the  Level  of  Interoperability  View, 
introducing  the  necessary  measures  of  merits  and  metrics  to  measure  interoperability  as  well  as  to  define 
the  level  of  necessary  interoperability  to  reach  a  requirement  driven  solution. 
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Figure  4:  A  Possible  C4ISR/Sim  TRM  Framework 


All  three  Study  Groups  of  SISO  coping  with  M&S  to  C3I  Interoperability  used  the  model  introduced  by 
Carr  and  Hieb  in  [16]  and  improved  it  gradually.  Although  the  model  is  mainly  focussing  on  the 
standardization  of  interfaces,  in  particular  the  data  to  be  exchanged  M&S  and  C3I  systems,  and 
furthermore  has  been  applied  mainly  in  the  domain  of  CAX4,  it  can  be  seen  as  one  of  the  most  matured 
and  applied  models  evaluated  by  SISO  in  this  context.  The  presented  version  is  not  the  end  state.  It  is 
much  more  likely  that  it  will  be  further  developed  and  improved.  In  particular  F.  Carr  has  to  be  mentioned 
in  this  context,  who  is  responsible  for  the  lion  share  of  the  improvements  being  done  in  the  course  of  the 
three  Study  Groups  (see  also  footnote  on  page  1-11). 

The  C4ISR/Sim  TRM  depicts  the  types  of  data  that  must  be  exchanged  between  C3I  and  simulation 
systems  in  order  to  conduct  effective  events.  As  used  here,  “effective”  means  satisfying  the  user 
requirements  for  an  event  (e.g.  fair  fight,  level  playing  field,  real-time,  data  capture  and  replay).  “Event” 


4  When  using  M&S  system  to  support  military  operations  as  decision  support  systems,  a  whole  new  set  of  requirements  must  be 
fulfilled,  see,  among  others,  Andreas  Tolk  and  Dietmar  Kunde:  “Decision  Support  Systems  in  the  Military  Environment”, 
Chapter  6  in  "Innovations  in  Decision  Support  Systems",  Tonfoni  G.  and  Jam  L.  (Eds.),  International  Series  on  Advanced 
Intelligence,  Advanced  Knowledge  International,  ISBN  0-86803-980-2,  Magill,  Adelaide,  Australia,  2003,  pp.  175-210 
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means  any  interaction  between  C3I  and  simulation  systems,  irrespective  of  the  purpose  (e.g.  training, 
testing,  planning,  analysis).  The  C4ISR/Sim  TRM  describes  four  broad  categories  of  information 
exchanged  between  C3I  and  M&S  systems,  which  are  Simulation  Service  Interactions,  Non-Persistent 
Data,  Persistent  Data,  and  C4ISR  System  Service  Interactions.  It  also  defines  subcategories.  For  the  exact 
definitions  and  examples,  please  refer  to  [7]. 
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Figure  5:  The  C4ISR/Sim  Technical  Reference  Model 


Simulation  Service  Interactions  are  information  exchanges  that  primarily  support  the  simulation  systems 
requirements.  This  category  includes  information  about  the  simulation,  and  information  necessary  to 
control  or  coordinate  its  execution  with  C3I  resident  activities.  Five  subcategories  are  Simulation 
Metadata,  Execution  Control,  Visualization,  Data  Collection,  and  Simulation  Effects. 

Non-Persistent  Data  is  data  that  will  likely  change  during  the  course  of  an  event.  The  interface 
mechanism  selected  for  Non-Persistent  Data  must  support  dynamic  updates.  Periodic  and/or  event  driven 
updates  may  be  required.  For  example,  a  simulated  entities’  position  may  be  sent  to  a  C3I  system  at  30 
Hertz,  or  only  when  triggered  by  a  dead  reckoning  algorithm.  Even  though  the  position  of  an  entity  may 
not  change  during  a  particular  event,  it  is  still  viewed  as  Non-Persistent  Data  because  it  is  subject  to 
change.  Non-Persistent  Data  refers  to  the  class  of  information  that  is  transient,  corresponding  to 
interactions  between  entities  or  objects  in  the  simulation  or  C3I  database,  or  updates  to  an  entity’s  state. 
Subcategories  are  Orders,  Reports,  Imagery,  Tracks,  and  Unit  Data. 

Persistent  Data  is  data  that  is  reasonably  static  and  generally  set  during  system  initialisation.  The  ability 
to  provide  direct  transfer  of  C3I  data  from  the  suggested  sources  to  simulation  equivalents  for  scenario 
initialisation  purposes  can  provide  substantial  cost  savings,  set-up  time  reductions,  and  increased 
flexibility  for  simulation  use.  So  far  identified  subcategories  are  Mission  &  Plan  Information, 
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Communication  Plans,  Weather  Data,  and  Terrain  Specifications. 

C4ISR  System  Sendee  Interactions  are  exchanges  of  information  that  may  be  mandated  by  use  of 
particular  C3I  components,  or  merely  by  virtue  of  being  connected  to  a  C3I  system.  They  may  not  contain 
data  that  is  exchanged  between  the  two  domains,  but  may  be  required  in  order  to  connect  to  the  C3I 
system,  sustain  the  connection,  or  to  use  a  particular  C3I  component.  So  far  identified  subcategories  are 
System  Reports  on  Health/Heartbeat/Status  needed  by  the  C3I  system  and  Component  Service  Protocols 
required  by  participating  C3I  systems. 

The  following  alternative  view  has  been  developed  by  the  author  based  on  the  C4ISR/TRM.  It  is 
primarily  intended  to  extend  the  view  from  CAX  to  Support  to  Operations  and  to  include  the  C3I  relevant 
components  on  the  level  of  the  GUM.  This  is  a  high  level  view  on  M&S  to  C3I  interoperability  and  is 
intended  to  extend  the  C4ISR/Sim  TRM  into  a  more  general  direction  (by  combining  the  Functions  and 
Data  View  and  the  Software  Components  View  as  introduced  in  Figure  4  into  one  model).  It  must  be 
pointed  out  that  this  view  is  actually  not  adopted  by  SISO  but  the  personal  view  of  the  author. 
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Figure  6:  High  Level  View  on  M&S  to  C3I  Interoperability 

In  addition  to  the  sourcebook,  a  user  guide  for  the  C4ISR/Sim  TRM,  as  developed  by  the  Study  Groups, 
will  be  published  [8].  The  five  primary  guiding  principles  for  developing  the  C4ISR/Sim  TRM  were,  that 
the  TRM  must  be  comprehensive,  easy  to  interpret,  traceable,  usable,  and  independent.  The  user  guide 
will  in  particular  help  to  make  the  model  easier  to  inteipret  and  more  usable. 
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6  SUMMARY 

The  three  Study  Groups  conducted  under  the  aegis  of  the  SIW  C4I  forum  of  SISO  within  the  recent  years 
help  tremendously  to  identify  burning  issues  within  the  domain  of  M&S  to  C3I  Interoperability.  All 
reports  and  interim  products  are  available  to  the  public  via  the  SISO  library  [21].  These  documents  are 
valuable  sources  for  everyone  being  interested  in  this  domain  of  increasing  importance. 

The  author  is  convinced  that  C3I  and  M&S  components  will  continue  to  merge  in  the  future.  The  recent 
developments  within  the  C3I  community  improved  the  command  and  control  capability  and  quality  in  on 
order  of  magnitude  by  replacing  the  messages  with  a  Common  Operational  Picture  (COP),  which  proofs 
the  saying  that  “a  picture  says  more  than  1,000  words.”  The  next  order  of  magnitude  improvement  will  be 
the  introduction  of  M&S  components  to  communicate  the  commanders  intend  in  a  much  more  efficient 
way,  which  could  be  stated  as  “a  simulation  execution  says  more  than  1,000  pictures.”  The  C3I 
community  is  still  driven  mainly  by  intelligence,  surveillance,  and  reconnaissance  resources,  driven  by  the 
requirement  to  create  a  consistent  picture  out  of  various  incomplete,  unsharp,  uncertain,  inconsistent,  and 
contradictive  pieces  of  information.  The  user  requirement  for  more  agile  support  leads  to  dynamical 
structures  as  being  supported  by  the  M&S  communities  since  years.  Both  communities,  M&S  and  C3I, 
have  essential  contributions  to  the  heterogeneous  information  infrastructure  to  support  the  Warfighter  in 
his  future  operations. 
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A  MULTI-NATIONAL,  DISTRIBUTED  TESTBED  FOR  EXTENDED  AIR 

DEFENCE  BMC3I,  PAST  EXPERIENCES  &  VISION  FOR  THE  FUTURE 

The  development  and  testing  of  the  BMCSIfor  NATO ’s  extended  air  defence  mission  has  many  challenges. 
The  BMC3I  element  is  responsible  for  the  coordination  and  integration  of  the  other  three  primary  EAD 
functional  areas:  Active  Defence,  Passive  Defence,  and  Conventional  Counterforce  and  can  involve 
weapon  and  sensor  systems  widely  distributed  over  land,  sea,  air,  and  even  space.  These  systems  may  be 
operated  by  individual  nations  or  integrated  into  NATO’s  command  and  control  structure  directly.  In 
addition,  the  missile  defence  aspect  of  extended  air  defence  is  relatively  new  to  military  operations,  with 
defensive  systems  capable  of  negating  ballistic  missiles  being  deployed  only  within  the  last  10  to  15  years. 
NATO  recognises  the  need  for  a  more  integrated  approach  to  countering  the  emerging  ballistic  missile 
threat  as  is  evidenced  by  the  recently  sponsored  NATO  Active  Layered  Theatre  Ballistic  Missile  Defence 
(TBMD)  Feasibility  Study. 

This  paper  summarizes  NCSA’s  use  of  modelling  and  simulation  in  support  of  NATO’s  EAD  mission, 
specifically  in  the  area  of  C2  interoperability  at  the  technical,  systems,  and  operational  levels.  It  provides 
a  summary  of  lessons  learned  from  Cannon  Cloud  ’02  and  other  similar  NATO  exercises.  It  gives  an 
overview  of  some  on  -going  activities  that  are  aimed  at  developing  a  strategy  for  a  more  cohesive, 
coordinated  approach  to  the  employment  ofM&S  in  support  of  EAD  C2  within  the  NATO  community,  and 
some  insights  into  what  that  future  environment  might  look  like. 
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1.0  INTRODUCTION 

1.1  NATO  C3  Agency 

The  NATO  C3  Agency  (NC3A)  was  established  on  1  July  1996  to  provide  consultation  and  scientific 
support  to  NATO  and  is  overseen  by  the  NATO  C3  Organization  (NC30).  Formation  of  the  Agency  was 
achieved  by  the  amalgamation  of  the  former  SHAPE  Technical  Centre  (STC)  and  the  NATO 
Communications  and  Information  Systems  Agency  (NACISA).  The  NC3A  is  located  in  two  facilities:  one 
in  The  Hague,  Netherlands  and  one  in  Bmssels,  Belgium.  The  NC3A  operates  under  the  policy  direction 
of  the  NATO  C3  Board. 

The  NC3A  has  two  fundamental  missions  as  defined  in  the  charter  of  the  NC30.  The  first  is  to  develop 
and  implement,  in  a  timely  manner,  cost-effective  communications  and  information  system  capabilities  to 
support  NATO’s  functions  pertaining  to  both  Political  Consultation  and  Military  Command  and  Control. 
The  second  mission  is  to  provide  unbiased  scientific  advice  and  assistance  to  NATO’s  military  and 
political  authorities. 

1.2  Missile  Defence  Branch 

The  work  discussed  in  this  paper  was  performed  by  the  NC3A  Missile  Defence  (MD)  Branch,  which 
performs  a  lead  role  in  several  important  efforts  supporting  NATO’s  missile  defence  mission  area.  Most 
notable  are  the  Active  Layered  TBMD  Feasibility  Study,  the  Missile  Defence  Feasibility  Study,  and  the 
NATO/Russia  TMD  Interoperability  Study.  In  addition  to  these,  the  NC3A  Scientific  Programme  of  Work 
(SPOW),  sponsored  by  NATOs  Bi-Strategic  Commanders,  funds  the  development  of  the  PLATO  and 
LSID  operational  prototypes  as  well  as  the  NC3A  portion  of  the  MDA/SHAPE  Bi-Lateral  BMC3  Study. 
PLATO  (Planning  Tool)  is  NC3A’s  operational  prototype  for  exploring  missile  defence  planning  and 
tasking  requirements  and  functionality.  LSID  (Linkl6  SAMC2  Interoperability  Demonstrator)  is  NC3A’s 
operational  prototype  for  exploring  the  BMC3I  requirements  associated  with  real-time  control  and 
coordination  of  ballistic  missile  engagements.  These  activities  are  all  aimed  at  capturing  requirements  for 
NATO’s  missile  defence  mission  area  with  the  SPOW  activities  particularly  focused  on  NATO’s  missile 
defence  BMC3I  interoperability  issues,  and  exploring  synergies  between  functional  components  of  MD 
(ActD,  PD  and  CCF). 

Missile  defence  in  NATO  is  a  multi-dimensional  operational  domain.  It  addresses  potential  threat  systems 
of  all  types,  various  levels  of  the  NATO  command  structure,  a  diverse  set  of  interface  exchange 
requirements,  and  three  main  functional  areas  for  negating  the  missile  threat.  NATO’s  emerging  BMC3 
systems,  ACCS  &  the  Bi-SC  AIS,  will  have  to  efficiently  address  all  of  these  dimensions. 

To  adequately  capture  the  requirements  associated  with  these  dimensions,  the  Missile  Defence  Branch 
uses  a  cyclical  process  utilising  a  combination  of  modelling,  simulation,  and  operational  prototypes.  The 
requirements  are  initially  generated  based  upon  the  results  coming  out  of  studies  and  analysis  activities. 
The  requirements  are  then  implemented  in  prototype  software  where  they  can  be  explored  for  technical 
feasibility  in  detail.  The  emerging  requirements  (as  implemented  in  the  prototype  software)  are  then  put  in 
front  of  operators  in  realistic  experiments  and  exercises  to  evaluate  them  with  respect  to  their  operational 
utility  and  usefulness.  The  process  repeats  with  more  and  more  insight  and  detail  being  developed  after  the 
completion  of  each  phase.  With  this  approach,  BMC3I  requirements  can  be  generated  quite  rapidly  even  in 
a  complex  mission  area  like  missile  defence.  They  can  then  be  included  in  the  development  programmes 
for  NATO  BMC3I  systems  (e.g.,  future  enhancements  to  ACCS  or  the  Bi-SC  AIS.) 
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1.2  Interoperability  at  all  levels 

Most  NATO  BMC3I  systems  share  a  common,  fundamental  concern:  interoperability.  If  the  BMC3I 
system  does  nothing  else,  it  is  usually  required  to  make  sure  that  its  systems  work  together.  In  NATO 
missile  defence,  the  BMC3I  element  is  responsible  for  the  coordination  and  integration  of  weapon  and 
sensor  systems  developed  by  different  nations  and  widely  distributed  over  land,  sea,  air,  and  even  space. 

Interoperability  has  to  be  addressed  at  several  levels.  First  of  all  is  the  technical  level:  systems  need  to  be 
connected  to  each  other  properly  before  they  can  start  communicating.  Then  there  is  the  system  level  of 
interoperability:  systems  need  to  communicate  using  a  common  protocol  and  message  standard.  And 
finally  there  is  the  operational  level  of  interoperability:  each  system  needs  to  fully  understand  the  contents 
of  the  other’s  messages  and  know  how  that  data  relates  to  its  own  information. 

One  problem  we  tend  to  run  into  in  missile  defence  BMC3I  analyses  is  that  we  focus  so  intently  on  the 
interoperability  issues  associated  with  the  real-world  BMC3I  systems  that  we  forget  to  properly  deal  with 
the  interoperability  issues  associated  with  the  models  and  simulations  we  use  in  evaluating  them.  We  end 
up  “solving”  our  M&S  interoperability  problems  over  and  over  again,  for  each  experiment  we  run,  and  for 
each  exercise  we  participate  in.  Our  lessons  learned  are  usually  lessons  re-leamed,  and  the  solutions  tend 
to  be  applicable  only  for  a  given  set  of  models  and  exercise  objectives. 


2.0  CANNON  CLOUD  2002 

We  will  now  describe  the  2002  Cannon  Cloud  exercise,  as  a  case  study,  to  illustrate  how  the  MD  branch 
supports  NATO  exercises  and  the  issues  that  are  typically  encountered  in  such  activities. 

2.1  Exercise  overview 

Cannon  Cloud  2002  (CC02)  was  the  second  largest  exercise  on  the  NATO  calendar  for  that  year.  It  was  a 
large,  multi-corps,  multi-CAOC,  computer  aided  exercise  (CAX)  conducted  at  USAF  Europe  (USAFE) 
Warrior  Preparation  Centre  (WPC)  in  Einsiedlerhof,  Germany,  and  a  number  of  other  locations.  The 
primary  emphasis  of  CC02  was  to  support  higher  echelon  operational  training  for  coalition  forces  in  a 
large  scale,  high  intensity  conflict  using  the  Joint  Theatre  Level  Simulation  (JTLS),  an  aggregate 
simulation  that  has  served  as  the  SHAPE-approved  CAX  simulation  since  1995.  Missile  defence  was  only 
one  part  of  the  overall  exercise  objectives. 

The  role  of  the  MD  Branch  at  the  CC02  exercise  was  to  provide  the  hardware,  software  and 
communications  capability  required  to  provide  detailed  simulation  of  TMD  activity  of  suitable  fidelity 
such  that  the  training  objectives  of  the  Joint  TMD  Cell  (JTMDC)  could  be  achieved. 

The  exercise  scenario  for  CC02  utilized  actual  Northern  European  terrain  with  fictitious  national 
boundaries.  The  Tactical  Ballistic  Missile  (TBM)  threats  were  operated  by  the  coalition  of  Oliveland  and 
Orania  against  the  Southern  region  of  Montrena  (figure  1).  The  mission  of  NATO  missile  defence  in  this 
exercise  was  to  protect  NATO  forces  in  Montrena  from  TBM  attack  through  Active  Defence  (ActD)  and 
Conventional  Counter  Force  Operations  (CCFO)  against  the  threat  coalition  to  ensure  that  threat  TBM 
infrastructure  and  support  systems  could  be  destroyed  prior  to  TBM  launch.  All  functional  areas  of  TMD 
were  to  be  fully  integrated,  first  of  all  with  each  other,  but  also  into  the  overall  exercise. 
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Figure  1:  Cannon  Cloud  2002  country  book 


2.2  NATO  TMD  Doctrine 

CC02  exercised  all  four  functional  areas  of  NATO  TMD  doctrine.  Conventional  Counterforce  Operations: 
to  prevent  an  aggressor  from  launching  ballistic  or  other  types  of  missiles  by  attacking  identified  launch 
areas  and  associated  sites.  Active  Defence:  to  engage  theatre  ballistic  missiles  in-flight.  Passive  Defence: 
to  mitigate  the  effects  of  an  attack  via  camouflage,  hardening,  dispersal,  deception,  and  by  providing  early 
warning.  BMC3I:  to  integrate  and  coordinate  the  activities  of  the  other  three  functional  areas  in  order  to 
efficiently  and  effectively  negate  the  ballistic  missile  threat. 

During  CC02,  Conventional  Counterforce  Operations  were  supported  by  the  CAESAR  simulations  for 
Alliance  Ground  Surveillance  platforms,  Active  Defence  was  simulated  by  EADSIM,  and  Passive 
Defence  was  provided  using  the  operational  NATO  Shared  Early  Warning  (SEW)  system.  The  JTMDC 
acted  as  the  hub  of  the  Battle  Management/Command,  Control,  Communications,  Computers  and 
Intelligence  (BMC3I)  capabilities  required  to  coordinate  Conventional  Counterforce  Operations  and 
Passive  Defence. 

2.3  The  aggregation  problem 

One  of  the  fundamental  challenges  encountered  in  supporting  CC02  with  M&S  was  the  issue  of  dissimilar 
levels  of  unit  aggregation  between  models.  JTLS,  the  core  simulation  for  the  exercise,  usually  aggregates 
units  to  the  brigade  level  or  larger.  Mission  specific  simulations  like  OneSAF  and  EADSIM  usually 
represent  units  at  the  entity  level  in  order  to  accurately  capture  the  detailed  effects  of  signature  and 
kinematics.  The  challenge  then  is  to  find  a  way  for  these  dissimilar  models  to  operate  together. 

Figure  2  captures  the  nature  of  the  multi-resolution  modelling  problem  encountered  during  CC02.  In  the 
middle  is  a  close-up  of  the  hexagon  system  used  by  the  exercise  planners  to  represent  the  battle  space. 
Each  hex  is  7  kilometres  across. 
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Joint  Theatre  Level 
Simulation  (JTLS) 


Operational  Testbed  (OneSAF) 


Figure  2:  Cannon  Cloud  2002  aggregation  problem 

On  the  right  is  a  representation  of  an  entity- level  simulation  used  by  the  CAESAR  sensor  simulations  for 
Conventional  Counterforce  Operations.  Individual  buildings,  trees,  100-meter  resolution  terrain  data  and 
roads  are  all  represented  in  the  AGS  simulation  world. 

The  errors  that  arise  when  combining  such  simulations  can  be  generalised  as: 

•  Time  synchronisation,  especially  when  considering  moving  targets, 

•  Location  errors  are  clear  when  you  consider  that  JTLS  generalises  features  across  7km, 

•  Velocity,  road  registration  and  features  are  also  of  concern. 

The  challenge  was  to  develop  an  architecture  to  address  these  issues. 

Ligure  3  shows  the  architecture  that  was  designed  to  support  the  TMD  operations  and  to  address  the  issues 
mentioned  above.  The  architecture  minimises  the  effects  of  concurrently  running  dissimilar  simulations. 

JTLS,  again,  is  the  primary  simulation.  TBM  units  operated  on  pre-planned  schedules  represented  by 
scripts  in  ITEST  and  in  JTLS.  JTLS  issues  the  TBM  fire  command  to  EADSIM,  which  then  flies  the 
ballistic  missile  and  conducts  the  intercept  using  Dutch  and  German  Patriot  units  and  the  Dutch  Navy 
Lrigate.  When  the  EADSIM  launch  occurs,  the  HLA  listener  relays  the  launch  information  to  the  SEW 
Alerter,  which  injects  the  launch  warning  information  into  the  NATO  WAN.  On  the  AGS  side,  the  sensors 
detect  the  moving  entities  of  ITEST  and  feed  exploitation  systems  using  the  common  data  format  (NATO 
EX).  This  allows  the  sharing  of  national  sensor  system  data. 
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Figure  3:  Cannon  Cloud  2002  TMD  simulation  architecture 

This  architecture  solution  worked  and  TMD  objectives  of  the  exercise  were  achieved.  However,  the  use  of 
multiple,  simultaneously  running  scripts  (one  for  JTLS  and  one  for  ITEST)  was  prone  to  synchronisation 
problems,  had  the  potential  for  data  mismatch,  and  did  not  allow  the  exercise  planners  much  flexibility  to 
dynamically  change  the  course  of  events.  In  short,  the  solution  worked,  but  required  quite  a  bit  of  effort  to 
set  up  and  to  keep  events  and  data  synchronised. 

Another  issue  that  arose  during  CC02  was  an  appreciation  for  the  huge  number  of  entities  required  to 
accurately  reflect  background  traffic  for  the  AGS  simulations.  If  not  managed  properly,  these  entities 
would  quickly  swamp  computer  and  network  resources. 

The  typical  modefto-model  interoperability  issues  were  also  encountered.  Although  HLA  was  used  as  the 
interface  between  JTLS  and  EADSIM,  both  simulations  lacked  FOM  agility.  This  resulted  in  a  FOM  that 
was  driven  more  by  what  the  models  could  be  made  to  easily  produce  than  by  the  CC02  exercise 
requirements.  The  developers  of  both  tools  were  needed  to  achieve  a  functioning  federation,  and 
specialised  software  versions  were  created.  While  the  TMD  objectives  for  the  exercise  were  met,  it 
required  a  large  investment  in  time  and  manpower  to  achieve.  These  issues  are  by  no  means  peculiar  to 
these  models  or  this  exercise.  In  our  opinion,  they  represent  a  common  set  of  challenges  that  are  faced  in 
most  distributed  experiments  and  exercises. 


3.0  VISION  FOR  THE  FUTURE 

CC02  is  only  one  example  of  the  many  types  of  activities  the  MD  Branch  is  requested  to  support  with 
M&S  and  prototyping.  It  is  a  useful  example  in  that  it  brings  attention  to  the  various  problems  and 
challenges  associated  with  M&S  support  for  large  scale,  distributed  exercises.  However,  as  mentioned 
previously,  it  is  also  illustrative  of  the  constraints  that  any  future  M&S  activity  is  likely  to  encounter. 
Some  of  these  constraints  include: 
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•  Exercise/experiment  specific  goals,  objectives,  and  requirements. 

•  Limited  NC3A  manpower  and  specialised  expertise. 

•  A  mixture  of  DIS  and  HLA  compatible  models  and  prototypes. 

•  For  HLA  compatible  models  and  simulations,  the  SOMs  will  almost  certainly  not  map  directly  to 
each  other. 

•  Lack  of  access  to  source  code  and/or  simulation  developers. 

•  Potentially  large  number  of  entities  (especially  for  AGS  applications). 

•  Never  enough  time. 

These  must  all  be  taken  into  account  as  we  formulate  our  vision  for  a  missile  defence  interoperability 
testbed  at  NC3A. 

3.1  The  NC3A  Missile  Defence  Interoperability  Testbed 

The  overall  objective  of  the  NC3A  Missile  Defence  Interoperability  Testbed  is  to  create  an  environment 
for  addressing  missile  defence  interoperability  issues  in  the  near-term.  We  want  to  create  an  environment 
where  the  M&S  interoperability  issues  are  addressed  up  front  and  independent  of  any  particular  exercise 
or  experiment.  We  want  these  issues  resolved  in  a  way  that  allows  our  analysts  to  focus  on  the  branch’s 
primary  functions  of:: 

•  Verification  and  validation  of  NATO’s  command  and  control  concepts  of  operations  for  missile 
defence. 

•  Identification  and  evaluation  of  missile  defence  C2  system  requirements. 

•  Test  and  evaluation  of  missile  defence  prototype  software. 

•  User-in-the-loop  concept  evaluation. 

The  testbed  should  provide  an  environment  that  allows  us  to  perform  these  functions  without  creating  an 
unduly  large  burden  on  the  branch.  In  other  words,  the  testbed  should  support  the  existing  objectives  of 
the  Missile  Defence  Branch  and  NC3A,  and  not  become  an  objective  in  and  of  itself. 

This  environment  will  also  need  to  support  all  three  of  the  major  types  of  activities  that  the  branch 
performs.  These  activities  as  described  previously  include,  Studies  and  Analyses,  Prototype  Development, 
and  Exercise/Experimentation.  The  testbed  must  support  all  three  types  of  activities  and  provide  as  much 
commonality  as  possible  to  ensure  the  smooth  transition  from  one  activity  type  to  another,  while 
minimising  training  and  manpower  costs. 

NATO  is  currently  tasked  with  providing  an  effective  missile  defence  of  its  deployed  forces.  It  must 
perform  this  mission  using  an  assortment  of  weapon  and  sensor  systems  provided  by  the  NATO  member 
nations.  With  this  in  mind,  it  is  easy  to  see  why  operational,  system,  and  technical  interoperability  are 
among  NATO’s  highest  priority  challenges.  The  focus  of  the  Missile  Defence  Branch,  and  therefore  this 
testbed,  is  on  missile  defence  interoperability  issues  associated  with  real-time  and  non-real-time  C2 
functions.  The  testbed  must  address  and  facilitate  the  identification  of  data  exchange  requirements,  the 
exploration  of  potential  synergy  between  the  functional  areas  of  missile  defence,  and  the  raising  of  real- 
world,  missile  defence  BMC3  issues  before  weapon,  sensor,  and  C2  systems  are  fielded  in  an  operational 
setting. 

The  testbed  vision  described  in  this  document  addresses  a  specific,  near-term  missile  defence  need  within 
NATO.  One  of  the  conclusions  coming  out  of  NATO’s  Active  Layered  Theatre  Ballistic  Missile  Defence 
Feasibility  Study  (ALTBMD  FS)  is  the  need  for  a  testbed  to  reduce  the  schedule  risks  associated  with  the 
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integration  of  a  variety  of  weapon,  sensors,  and  BMC3  systems.  By  establishing  a  distributed  testbed 
capability,  integration  and  interoperability  issues  can  be  identified  and  resolved  well  in  advance  of  system 
fielding.  As  part  of  the  Capability  Package  resulting  from  the  ALTBMD  FS,  an  Integration,  Test,  and 
Evaluation  Testbed  is  being  proposed  with  an  estimated  2006  IOC  date. 

The  problem  with  this  is  that  NATO’s  primary  C2  systems  that  will  be  used  to  plan,  task,  and  execute  the 
missile  defence  mission  (ACCS  and  Bi-SC  AIS)  are  in  development  now  with  the  initial  missile  defence 
requirements  being  analysed  and  developed  over  the  next  couple  of  years.  Also,  within  the  operational 
community,  the  missile  defence  CONOPS  are  currently  being  refined  and  evaluated  to  deal  with  ballistic 
missiles  of  extended  ranges  and  WMD  capabilities.  The  testbed  vision  described  in  this  paper  addresses 
these  near-term  needs  in  support  of  NATO  C2  system  requirements  capture  and  military  CONOPS 
development,  and  is  envisioned  as  a  bridge  to  the  future  integration  testbed  defined  in  the  ALTBMD  FS 
Capability  Package. 

Our  vision  of  a  useful  testbed  is  more  than  just  a  collection  of  models  that  can  exchange  information  with 
one  another.  It  includes  the  following  dimensions: 

•  Facility  related  infrastructure. 

•  Hardware  related  items. 

•  Core  simulations  and  models. 

•  Prototype  software. 

•  Distributed  simulation  capability  and  support  infrastructure. 

•  Analysis  tools. 

•  Support  staff  and  training. 

•  NATO  reference  databases. 

Each  of  these  areas  will  be  addressed  in  more  detail  in  the  following  sections. 

3.1.1  Facility  related  infrastructure 

The  facility  supporting  the  testbed  should  be  able  to  handle  NATO  security  levels  up  to  and  including 
NATO  Secret.  It  must  allow  repeated  access  to  military  and  technical  representatives  from  NATO  member 
countries  and  their  equipment,  and  have  the  necessary  NATO  network  connections  to  allow  remote 
participation  in  NATO  experiments  and  exercises. 

3.1.2  Hardware  related  items 

The  missile  defence  interoperability  testbed  should  have  a  robust  hardware  suite  available  to  it.  This 
hardware  suite  must  support  prototype  and  model  hosting,  a  centralised  server  capability,  sufficient 
storage  and  network  capacity,  communications  interfaces  to  distributed  locations,  as  well  as  a  well- 
documented  and  tested  backup  system.  The  objective  here  is  to  have  the  required  hardware  capability  and 
system  administration  processes  developed  and  in  place  before  (and  independent  of)  any  specific  exercise. 
This  will  provide  a  stable,  familiar,  and  well- documented  computing  environment  for  conducting  missile 
defence  experiments  and  exercises.  It  will  also  reduce  the  need  and  associated  risk  of  trying  to  acquire 
computing  and  network  hardware  to  support  a  specific  event. 

3.1.3  Core  simulations  and  models 

The  interoperability  testbed  can  be  thought  of  containing  two  broad  categories  of  simulations.  The  first 
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category  can  be  described  as  “core”  tools  that  model  theatre  level  interactions  and  effects.  Because  of  the 
limited  amount  of  available  manpower,  this  set  has  to  be  reduced  to  a  relatively  small  suite  of  models  that 
must  cover  a  range  of  capabilities  and  functions.  These  models  must  support  studies  and  analysis, 
prototype  development,  and  exercise/experimentation  objectives.  In  addition,  they  must  be  able  to 
exchange  information  with  each  other  either  by  common  data  structures  in  support  of  analysis  efforts  or  by 
distributed  simulation  techniques  such  as  HLA  (High  Level  Architecture)  or  DIS  (Distributed  Interactive 
System)  in  support  of  experimentation. 

The  second  category  can  be  described  as  weapon,  sensor,  and  C2  system  emulators.  These  will  vary  from 
experiment  to  experiment  and  will  often  be  supplied  and  supported  by  technical  experts  from  NATO 
member  nations.  This  set  also  includes  actual  weapon  and  sensor  system  hardware.  This  category  of 
simulator/emulator  is  distinguished  from  the  previous  set  of  models  and  simulations  in  the  following 
ways: 


•  The  emulator  functionality  is  narrowly  focused  on  the  functions  of  the  system  it  is  representing. 

•  NC3A  will  almost  certainly  not  possess  expertise  in  using  the  emulator. 

•  Like  the  theatre  level  simulations  access  to  source  code  is  usually  not  available,  but  access  to 
technical  experts  with  the  ability  to  make  code  changes  on  the  fly  is  not  unheard  of. 

In  general,  these  emulators  will  be  available  for  a  short  time  to  support  the  specific  exercise  or  experiment, 
and  will  then  be  removed. 

3.1.4  Prototype  software 

One  of  the  fundamental  objectives  of  this  interoperability  testbed  is  to  provide  an  environment  for 
stimulating  and  testing  NC3A’s  missile  defence  prototype  software.  The  prototypes  follow  a  spiral 
development  process  that  requires  continual  interaction  with  the  military  operations  community  with 
stimulation  from  realistic  representations  of  the  weapon  and  sensor  systems  they  will  be  controlling.  The 
following  attributes  describe  how  the  NC3A  prototype  software  differs  from  the  models  and  simulations 
described  in  the  preceding  section: 

•  Access  to  source  code  (primarily  written  in  Java) 

•  Continually  changing  software  in  response  to  emerging  operator  requirements 

•  Prototype  developers  are  not  necessarily  HLA  or  DIS  experts 

By  facilitating  the  mnning  of  experiments  using  NC3A’s  missile  defence  prototype  capabilities,  more 
frequent  iterations  can  be  made  in  the  spiral  development  process,  and  requirements  capture  can  be 
achieved  more  rapidly. 

3.1.5  Distributed  simulation  capability  and  support  infrastructure 

A  distributed  simulation  capability  is  a  prerequisite  for  the  interoperability  testbed.  The  testbed  must  allow 
for  the  inclusion  of  legacy  systems  still  using  DIS,  but  should  be  based  upon  HLA  and  take  advantage  of 
the  benefits  it  provides.  A  FOM  that  is  specific  to  the  needs  of  the  missile  defence  mission  area  should  be 
defined,  and  the  core  models  should  be  made  to  conform  to  it.  A  customised  FEDEP  (Federation 
Development  and  Execution  Process)  should  be  developed  for  the  interoperability  testbed  taking  into 
account  its  core  capabilities  and  reoccurring  elements  and  processes. 

One  particularly  important  aspect  of  this  distributed  simulation  capability  is  the  way  in  which  tactical  data 
links  (TDLs)  are  represented  and  accessed.  TDLs  are  the  basic  information  exchange  methods  by  which 
NATO’s  operational  and  technical  elements  communicate  with  each  other.  They  are  standardised  and 
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baselined  in  NATO  Standardization  Agreements  (STANAGs)  signed  by  the  NATO  member  nations.  The 
interoperability  testbed  must  reflect  these  communication  standards  to  ensure  that  modelled  systems  are 
constrained  in  the  same  way  that  real-world  systems  are. 

Finally,  in-house  HLA  expertise  and  a  set  of  network/HLA  diagnostic  tools  are  necessary,  as  debugging 
and  analysing  distributed  experiments  can  be  extremely  difficult  and  time  consuming. 

3.1.6  Analysis  tools 

A  common  set  of  tools  designed  for  distributed  experiment  analysis  is  necessary  to  efficiently  collect, 
reduce,  and  display  the  results  of  an  experiment.  This  is  particularly  important  for  experiments  and 
exercises  where  a  large  number  of  people  are  involved.  As  distributed  experiments  tend  to  generate  large 
volumes  of  data  spread  across  multiple  computers,  this  can  also  be  a  very  challenging  task.  The  chief 
objective  here  is  to  allow  people  to  spend  their  time  addressing,  analysing,  and  discussing  the  experiment 
results,  not  waiting  for  the  results  to  be  collected  and  displayed.  The  ability  to  quickly  and  succinctly 
generate  “After  Action  Reports”  would  also  be  extremely  useful. 

3.1.7  Support  staff  and  training 

To  run  this  testbed  effectively,  a  team  of  trained  and  experienced  staff  are  necessary.  As  staffing  levels  are 
always  lower  than  desired,  the  testbed  support  staff  needs  to  consist  of  flexible  individuals  with  expertise 
in  multiple  areas  including:  technical  management,  core  simulation  expertise,  HLA/DIS  federation 
construction  and  execution  issues,  as  well  as  computer  hardware,  software  development,  and  network 
experience.  These  individuals  must  also  be  able  to  effectively  communicate  with  technical  staff  supporting 
other  event  specific  applications  as  well  as  personnel  from  the  military  operational  community 

3.1.8  NATO  reference  database 

The  final  dimension  that  makes  up  our  vision  of  a  missile  defence  interoperability  testbed  is  access  to  a 
well-defined  and  sanctioned  set  of  NATO  reference  databases.  These  databases  include  environment 
models  (e.g.,  terrain,  standard  atmosphere,  earth  spheroid,  etc)  as  well  as  threat  representations, 
weapon/sensor  system  models,  and  standard  scenarios  blessed  by  the  NATO  military  staff.  In  addition, 
these  databases  should  include  reference  architectures,  command  structures,  and  BMC3I  models  for 
NATO  ACCS  and  Bi-SC  AIS  entities.  These  databases  must  be  accessible,  controlled,  and  maintained. 
The  objective  is  to  have  the  desired  data,  ready  to  go,  with  no  development  or  set-up  time  required. 

3.1.9  Potential  software  and  network  components 

Having  addressed  some  of  the  general  features  of  our  testbed  vision,  it  s  now  useful  to  look  at  some 
potential  software  and  network  components  to  start  to  get  more  specific  and  identify  a  roadmap  for 
achieving  our  vision.  Figure  4  above  shows  the  different  categories  of  models,  simulations,  and  software 
tools  and  reinforces  some  of  the  points  made  in  the  previous  discussions.  The  important  thing  to  note  is 
that  any  particular  exercise  or  experiment  will  contain  only  a  subset  of  the  elements  listed.  The  key  then  is 
to  identify  a  set  of  core  models  and  a  flexible  infrastructure  that  will  facilitate  the  inclusion  of  a  variety 
system  emulators  and  prototypes. 
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Theatre  Simulations/"Environment  Generators “ 
JSAF/ONESAF/OTB 
EADSIM 
EADTB 
JTLS 
ITEST 
ITC 


Sensor  Systems  &  Emulators 

•  Ground  Surveillance 

•  CRESO 

•  VSTARS 

•  HORIZON 

•  AFRL  SIM 

•  RADARSAT  II 

•  CREWS 

•  MTTX 

•  Air  Surveillance 

•  NAEW  Sim 

•  JLENS  Sim 

•  NATO  EW  Sensor  Sims 

•  Maritime  Surveillance 


Weapon  Systems  &  Emulators 

•  Patriot  RTOS 

•  SAMOC 

•  THAAD  Sim 

•  Medusa  (Aegis  Weapon  System  Sim) 


BMC3  System  Prototypes 
•  NC3A  Software 
SEW 
LSID 

AGS  Exploitation 
PLATO 
ICC 
Other 

•  ACCS  (STVF) 


Testbed  Infrastructure 

•  Display,  Demonstration,  <&  Playback  Tools 

•  Analysis  Tools 

•  HLA/DIS/Network  Performance  Analysis 

•  Architecture/CONOPS  Analysis 

•  Gateways  &  Bridges 


Figure  4:  Different  categories  of  models,  simulations,  and  software  tools  for  the  testbed. 

As  we  move  to  a  more  specific  vision  of  the  future,  it  is  also  useful  to  think  about  how  the  NC3A  Missile 
Defence  Interoperability  Testbed  will  relate  to  the  ACCS  System  Test  and  Validation  Facility  (STVF)  as 
well  as  national  test  facilities.  Our  vision  is  that  the  NC3A  Missile  Defence  Interoperability  Testbed  will 
provide  a  fundamental  part  of  the  Integrated  Test  and  Evaluation  Testbed  when  it  comes  on-line  in  the 
2006  time  frame.  Connecting  operational  prototypes  at  NC3A  with  the  ACCS  system  software  at  the 
STVF  and  weapon  and  sensor  simulations  at  national  facilities  will  allow  NATO  to  explore  new  C2 
CONOPS  as  well  as  validate  technical  information  exchange  requirements  and  implementations. 

3.2  NC3A  HLA  Initiative  -  Objectives  &  Goals 

So  far  we  have  discussed  our  overall  testbed  philosophy  and  vision.  We  have  also  provided  a  brief 
description  of  what  we  think  our  testbed  will  look  like  in  the  future  and  how  it  will  relate  to  other  missile 
defence  testbed  facilities  that  exist  or  are  planned.  However,  before  concluding,  we  would  like  to  discuss 
two  current,  on-going  activities  that  are  aimed  at  taking  concrete  steps  towards  achieving  our  vision  of  a 
missile  defence  interoperability  testbed. 

The  first  activity  is  the  HLA  Testbed  Initiative  that  is  being  conducted  by  the  Missile  Defence  Branch  and 
TNO.  The  project’s  primary  objective  is  a  report  summarizing  a  set  of  recommendations  for  the 
development  of  an  HLA  federation  to  support  NC3A’s  Missile  Defence  Interoperability  Testbed.  This 
report  is  to  be  accompanied  by  a  proof -of -principle  experiment  demonstrating  the  viability  of  the  report’s 
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recommendations.  Specific  areas  addressed  by  effort  are:  FOM  agility  options  for  simulations  developed 
by  3rd  parties,  RTI  selection,  and  ways  to  facilitate  HLA-enabling  of  the  branch’s  JAVA-based  prototypes. 
The  proof -of-principle  demonstration  will  include  EADSIM,  EADTB,  LSID,  and  the  SEW  display 
software.  EADSIM  and  EADTB  represent  the  category  of  large,  theatre-level  simulations  that  are 
deployed  without  source-code  and  have  differing  HLA  implementation  approaches.  The  LSID  and  SEW 
software  represent  the  class  of  federates  that  are  developed  by  NC3A.  These  NC3A  developed  prototypes 
can  be  modified,  and  their  inclusion  is  meant  to  test  the  ease  with  which  they  can  be  integrated  into  an 
HLA  federation.  This  initiative  is  close  to  completion,  and  will  form  the  basis  for  the  Missile  Defence 
Branch’s  HLA  implementation  approach  for  the  Interoperability  Testbed. 

3.3  MSG-006/TG-006  Participation 

The  second  major  activity  supporting  NC3A’s  missile  defence  interoperability  testbed  implementation  is 
our  participation  in  the  NMSG’s  MSG-006  Task  Group.  This  task  group  was  established  to  investigate 
“M&S  Support  to  Assessment  of  Extended  Air  Defence  C2  Interoperability”  in  a  NATO  environment.  The 
task  group’s  objectives  include  evaluation  of  the  feasibility  of  reusing  existing  simulation  components  and 
testbeds  across  NATO  in  an  integrated,  distributed  fashion.  In  addition,  and  perhaps  more  importantly,  the 
task  group  will  recommend  approaches  to  distributed  simulation  architectures  that  will  enable  extended  air 
defence  C2  interoperability  analysis.  This  will  include  the  development  of  a  recommended  reference  FOM 
and  a  FEDEP  tailored  for  extended  air  defence.  While  the  HLA  testbed  initiative  project  addresses  issues 
such  as  how  to  get  federates  to  use  a  common  FOM,  one  of  the  important  products  of  the  MSG-006  task 
group  will  be  a  recommendation  on  what  objects  and  interactions  should  be  included  in  that  FOM.  This  is 
critical  if  the  missile  defence  analysis  community  is  going  to  take  full  advantage  of  the  benefits  that  HLA 
can  provide. 


4.0  SUMMARY 

In  summary,  NC3A  depends  heavily  upon  the  use  of  modelling  and  simulation  to  support  missile  defence 
C2  interoperability  analyses  for  NATO.  Experiences  at  Cannon  Cloud  ’02  and  other  similar  NATO 
exercises  demonstrate  the  need  for  a  missile  defence  testbed  that  allows  analysts  to  focus  on  the  C2 
interoperability  issues  rather  than  the  M&S  interoperability  issues.  For  this  to  occur,  a  set  of  objectives 
and  requirements  for  a  testbed  environment  is  needed  and  must  be  followed  by  a  concerted,  focused 
implementation  effort.  The  Missile  Defence  Branch  has  identified  what  such  an  environment  would  look 
like  and  is  involved  in  specific  activities  that  are  aimed  at  achieving  it. 
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Abstract 


In  this  paper,  TUBITAK’s  (Technical  and  Scientific  Council  of  Turkey)  experience  in  C4ISR 
domain  and  a  simulation  tool  being  developed  are  summarized. 


1  Introduction 

Nowadays,  C4ISR  as  an  integrated  military  structure  attracts  more  emphasize  in  parallel  to 
developments  on  information  technologies  and  knowledge  engineering.  C4ISR  systems  merge 
both  physical  components  and  information-oriented  aspects  like  decision-making  and 
message  exchange  between  participating  components.  Combining  both  world  layers,  physical 
and  infonnation,  provides  wider  worldviews  allowing  modelers  and  analysts  to  design 
inclusive  and  comprehensive  defense  simulation  tools  addressing  war  games,  C2  analysis, 
concept  development  and  gaining  management  experiences  on  them.  In  simulation  literature, 
information  and  physical  items  flows  are  known  as  opposite  to  each  other.  Bringing  both 
flows  together  and  satisfying  analysis  requirements  of  being  together  is  not  an  easy  task 
making  more  elegant  modeling  approach  especially  for  reusability,  modularity  and 
interoperability,  mandatory.  As  an  integrated  and  complicated  domain,  the  problem  of  C4ISR 
concepts  development  as  well  as  staff  training  generally  requires  experimenting  on  complex 
scenarios.  Simulating  these  scenarios  in  virtual  environments  and  coupling  them  to  real 
C4ISR  systems  and  staff  is  significantly  cost-effective  solution  for  the  problem  [1]. 

From  the  simulation  point  of  view,  modeling  information  layer  is  pretty  different  from 
modeling  physical  layer.  Variety  of  information  types,  concurrency,  probabilistic  nature  of 
information  and  its  flow  among  operational  nodes,  in  addition  to  all,  infeasibility  of  fully 
automated  decision  making  as  well  as  data  fusion  make  modeling  a  very  complicated  task.  So, 
that  requires  knowledge  intensive  and  highly  autonomous  components  in  addition  to  well- 
formulated  mathematical  models  solvable  by  operational  research  methods.  This  reveals  man- 
in-the-loop  simulation  as  a  practical  solution  for  the  problem.  That  is  one  of  the  essential 
factors  for  planning  C4ISR  simulation  tools  interacting  with  human  in  run  time. 
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TUBITAK  is  developing  an  open,  reusable,  modular  and  interoperable  simulation  system  for 
modeling  and  executing  C4ISR  architectures.  This  paper  summarizes  the  lessons-leamed  up- 
to  now  and  relevant  projections  for  future.  The  simulation  system  has  an  open  architecture  on 
two  points.  The  first  point  is  generating  a  distributed  infratructure  consisting  of  reusable 
components.  This  is  achieved  by  setting  up  the  whole  system  on  HLA/RTI  middleware;  it  is 
possible  to  insert  external  simulation  or  software  components,  even  in  run-time  to  a  scenario 
which  is  being  executed  as  a  federation  as  well  as  deploying  the  components  in  other  HLA 
federations.  The  other  point  emphasizes  openness  to  new  developments  by  having  modular 
and  well-interfaced  component  architectures. 

The  system  could  serve  for  concept  development,  analysis  and  training  purposes.  Military 
Concept  development  is  achieved  by  being  able  to  try  different  scenarios.  They  consists 
architectures  of  C4I  and  SR  components  allowing  declaration  of  operational  information  flow 
among  each  other.  Results  of  scenario  execution  are  elaborated  using  the  analysis  functions  of 
the  system.  Analysis  outcomes  are  revised  to  restructure  the  scenario  for  better  architectural 
concepts.  The  analysis  has  done  in  two  ways;  in  the  classical  way,  as  is  the  simulation  post- 
data  analysis,  and  the  second  way,  optimization  for  component  behaviors  with  respect  flexibly 
defined  criteria.  Moreover,  trainees  are  faced  with  different  cases  in  scenarios  to  examine  and 
feedback  their  strong  and  weak  sides  in  developing  C2  decision  and  actions. 

The  following  sections  present  rationale  and  features  of  the  system. 

2  Rationale  For  C4ISR  Simulations 

Essential  idea  behind  the  C4ISR  concept  is  developing  system  of  entities  and  their 
interoperability  definitions  rather  than  entities  themselves.  Hence,  the  main  motivation  for 
C4ISR  simulation  systems  is  being  able  to  model  many  individual  and  interoperable 
components  into  one  common  integrated  virtual  environment.  Stressing  integrated  view 
follows  up  the  need  for  modeling  an  environment  promoting  analysis  of  architectural  concepts 
as  well  as  decision  making  of  corresponding  staff.  It  could  be  modeled  at  different  layers  of 
C2  process,  that  are;  modeling  multi-sensor  and  multi-source  data  fusion,  modeling  decision 
support  mechanisms,  modeling  whole  C2  staff  decision  making  process  as  well  as  modeling 
behavioral  and  decision  making  capabilities  of  enemy  forces.  For  such  analysis,  features 
concerning  infonnation  and  its  flow  within  organizations  should  be  involved  within 
simulation  models.  By  incorporating  information,  users  and  analysts  could  reason  about 
operational  success  of  components,  their  level  of  integration  as  well  as  amount  and  quality  of 
data  they  produce.  This  includes  examining  connectivity  effectiveness  and  perfonnance  issues 
about  information  amount  and  flows. 

Training  staff  and  testing  new  components  in  typical  and  extreme  situations  within  such  a 
broad  sense  (integrated  systems)  is  costly  and  in  some  cases  not  very  practical.  As  C4ISR 
scenarios  could  be  developed  and  executed  in  virtual  environments,  training  and  trials  of  real 
elements  becomes  matter  of  interfacing  the  systems  to  the  virtual  environments.  This  provides 
very  efficient  way  for  performance  examination  of  system  components  in  various  condition 


RTO-MP-MSG-022:  C3I  &  Modelling  and  Simulation  Interoperability 


3-2 


and  cases.  System  acquisition  policies  could  well  be  established  on  such  tests  done  using 
virtual  environments. 

Strategical  and  tactical  rehearsal  of  C4ISR  systems  needs  many  elements  to  be  fed  by  exercise 
context  of  scenarios  belonging  to  various  operational  cases.  Developing  realistic  operational 
cases  in  peacetime  is  partly  possible.  In  spite  of  the  fact,  nowadays  many  real-world  items 
could  be  well-featured  using  virtual  mediums.  Consequently,  C4ISR  modeling  and  simulation 
environments  offer  such  realistic  resemblence  to  its  real  world  operational  en  environmental 
conditions  counterparts.  This  is  used  in  strategical  and  tactical  rehearsals  involving  virtual 
C4ISR  context.  Strategic  and  tactical  confinement  as  well  as  force  organizations  subject  to 
geo-politic  and  doctrinal  considerations  that  vary  for  each  country.  Virtual  simulation 
environments  could  be  tailored  to  reflect  such  doctrinal  chracteristics. 

3  Purposes  Of  the  C4ISR  Simulation  Environment 

A  C4ISR  modeling  and  simulation  environment  development  project  is  currently  being 
carried  on  by  TUBiTAK.  It  involves  modeling,  simulation  and  analysis  capabilities  for 
various  C4ISR  architectures  emphasizng  ISR  missions.  It  will  consist  of  various  types  of 
component  models  running  as  HLA  federates  on  RTI.  Component  models  will  be  modular 
and  well  interfaced  letting  cast  of  different  scenarios.  The  system  will  allow  deployment  of 
C2,  Communication,  Computer,  and  ISR  component  models  and  definitions  appropriate  for 
both  physical  and  infonnation  layer.  Main  features  of  the  system  are  as  in  the  following. 

User  could  define  an  integrated  operational  scheme  by  having  tools  to  lay  down  components 
on  the  scenario  region  and  specifying  their  technical  and  operational  capabilities.  This  will 
provide  the  physical  layer  construction  of  the  scenario.  These  component  models  are  defined 
as  types  of  sensors,  communication  systems,  C2  systems  and  weapon  systems.  Another 
definition  will  involve  architectural  and  operational  integration  of  components  under  a 
common  command  and  control  structure.  There  will  be  definitions  on  organizational  features 
pertaining  to  operational,  system  and  technical  views  of  the  architecture.  This  will  give 
information  layer  designations. 

The  system  will  have  tools  allowing  static  and  dynamic  optimization  of  sensor  deployment, 
their  coverage  optimization  and  multi-sensor  route  planning.  User  could  define  cost  functions 
and  constraints  of  perfonnance  measures.  These  mesaures  could  be  defined  with  respect  to  the 
missions  of  scenario. 


Sensor  detection,  classification  and  identification  data  will  be  integrated  using  fusion  models. 
There  will  be  two  types  of  data  Fusion;  sensory  and  information  (commented  data)  data 
fusion.  This  capability  will  support  examining  how  the  fusion  concept  affect  decision  makers 
job.  Also  testing  various  fusion  approach  and  techniques  would  be  possible.  If  required 
tactical  picture  based  on  fused  data  will  be  avalibale  to  C2  staff. 


Analysing  different  C4ISR  architectures  under  various  conditions  will  add  measuring 
effectiveness  of  architectures  in  real-time  perfonnance,  tactical  criteria  and  infonnation 
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format  and  sufficiency  etc.  This  will  enhance  peacetime  review  of  organizational 
effectiveness  for  contingency  conditions. 


4  Branches  of  the  simulation  environment 

The  simulation  enviromnent  consists  of  “Scenario  design”,  “Scenario  engine”,  “Analysis”, 
“Optimization”,  “Autonomous  forces”,  ”  Communication”,  “Sensors”,  “fusion”  and  “map 
functions”  main  components. 

Scenario  design  tool  allows  modelers  to  define  scenarios.  Scenario  definition  phase  starts  with 
choosing  a  map  in  DTED  format.  Simulation  component  toolboxes  let  scenario  designer  to 
choice  any  components  and  place  on  the  map.  The  components  in  the  toolboxes  are  stable  and 
moveable  platforms,  communication  devices,  command  and  control  units,  personnel 
(including  enemy),  fire  support  units,  sensor  systems  and  man-made  structures  such  as 
milestones,  buildings,  borderlines,  watchman  tower  and  mine  fields.  All  components  are  in 
generic  form  and  have  their  own  attributes  that  can  be  edited  by  the  scenario  designer  to 
translate  them  into  more  specific  ones.  Moreover,  getting  the  components  in  the  scenario 
more  specific,  it  is  possible  to  equip  a  component  with  some  other  components  such  as 
assigning  a  pistol  to  a  private,  to  prepare  some  ready  to  use  scenario  components  such  as  route 
definition,  area  definition  and  assign  them  to  related  components  as  subcomponents.  Possibly, 
the  most  critical  definition  in  scenario  design  is  mission  declarations  consisting  of  what 
component  has  what  goal  and  how  they  succeed  them.  “  What ”  part  is  modeled  in  mission- 
task-activity  tree  structure.  Each  mission  and  its  tasks  have  their  own  “success  constraints” 
and  each  method  of  the  tasks  have  their  applicability  constraints  and  a  process,  namely  “How” 
part,  declaring  in  what  structure  the  methods  are  applied.  The  scenario  engine  accepts  the 
whole  declaration  to  implement. 

Scenario  engine  is  a  manager  agent  expanding  component  mission  definition  by  watching  the 
simulation  environment.  It  basically  checks  the  task  applicability  conditions  and  applies 
implementation  process  sending  messages  related  simulation  component  declaring  “what  to 
do”  and  gets  a  succeed  result  back. 

To  be  able  to  build  the  scenario  in  C4ISR  structure,  architectural  definition  components  are 
provided  to  ensure  C4ISR  completeness  of  scenarios.  Architectural  components  are 
summarized  under  three  main  headlines.  They  are  Operational  view,  System  view  and 
technical  view.  In  operational  view,  the  environment  provides  high-level  operational  concept 
graphic,  in  which  operational  nodes  are  defined  and  declared  what  the  simulation  components 
belong  to,  organizational  relationship  chart,  operational  node  connectivity  description, 
operational  node  connectivity  diagrams.  C2  hierarchies  and  Commander  responsibility  area 
and  types  are  defined  by  organizational  relationship  chart. 

System  view  is  related  with  assigning  the  system  to  the  tasks  to  do  and  the  communication 
devices  to  the  messages  defined  between  operational  nodes  by  operational  node  connectivity 
diagrams.  Technical  view  provides  a  series  of  interfaces  providing  opportunities  creating 
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queries  for  both  applicability  checking  of  activities  implemented  by  a  component  and 
suitability  checking  of  a  device  for  a  specific  task  or  choosing  the  better  device  for  it. 


Analysis  module  undertakes  two  central  tasks.  The  first  one  is  to  create  simulation  input  data 
such  as  random  number  values  form  theoretical  distributions,  random  number  streams.  The 
second  task  is  to  make  queries  on  execution  results  and  subject  to  statistical  analysis  such  jl, 
ANOVA.  This  task  is  also  used  for  performance  analysis. 

Cost-effective  optimum  sensor  deployment  and  sensory  platform  path  planning  are  main  task 
of  optimization  tool.  Optimization  finds  optimum  sensor  combination  allowing  maximum 
coverage  or  optimum  sensor  combination  under  some  budget  constraints.  Depending  on 
sensor  types,  sensor  models  pick  infonnation  from  environment  especially  enemy  sources  and 
send  command  layers  them  via  communication  devices  and  command  layer  make  decision 
fusing  the  information  coming  from  multiple  sources  by  data  fusion  algorithms. 

Map  functions  are  fundamental  for  visibility  and  coverage  area  computations  for  both  sensors 
and  communication  devices.  All  models  in  the  system  are  modeled  effect  modeling  approach 
rather  than  physical  modeling. 

5  HLA  Compatibility 

Each  scenario  will  be  a  different  HLA  federation  running  on  RTI  middleware.  To  support  this 
structure,  sensor,  communication,  platform,  staff  and  C2  components  are  represented  as 
federates.  Components  could  dynamically  publish  or  subscribe  object/attribute/interactions 
during  execution. 

The  system  could  run  in  real-time  and  logical  time  modes.  A  separate  coordinator  federate 
will  manage  time  and  phase  synchronization.  Also  preprocess,  execution,  post-process  and 
replay  functions  will  be  managed  by  coordinator  federate. 

Federates  are  structured  in  a  layered  fonn.  Model  calculations  and  federate  interface  will  be 
separate  modules  each  interacting  through  interface  functions.  This  will  enhance  replacing  the 
calculation  side  with  others  having  different  approach  and  implementation. 

On  the  other  hand  federated  component  models  could  be  deployed  into  separate  processors. 
Higher  performance  would  be  achievable  when  the  system  is  loaded  with  a  complex  scenario. 
Also  training  features  will  be  promoted  by  breaking  up  each  federate  onto  separate  computer. 
Federate  user  interfaces  support  this  capability.  Consequently  each  C2  federate  user/operator 
could  see  the  tactical  picture  of  its  own  knowledge  base. 

6  Usage  Concepts 

The  simulation  tool  is  planned  to  be  used  aspecially  in  four  main  domains.  These  are 
1)  Training, 
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2)  Rehearsal, 

3)  Analysis  and 

4)  Optimization 

In  training  purpose,  users  are  expected  to  get  insight  some  fundamental  sensor  usage 
concepts.  Rehearsal  is  thought  mostly  to  improve  talents  of  tactical  analysis  and  tactical 
planning  capabilities  of  users. 

The  main  stress  on  Analysis  module  is  performance  analysis.  The  aim  is  to  put  differences 
between  users  forward  and  to  watch  their  improvements. 

Optimization  is  for  planning  purposes.  The  planning  consists  of  deployment  of  sensors  on  an 
area,  combination  of  sensor  type  and  numbers,  and  movable  sensors’  path  planning  so  that 
maximum  coverage  is  satisfied  under  cost  constraints. 

7  Results 

The  main  characteristic  of  the  study  is  the  effort  to  bring  together  information  layer 
simulation  together  with  the  layer  in  which  models  of  real  world  physical  entities  are 
simulated.  This  effort  matches  what  C4ISR  aims  to  do. 

The  simulation  tool  has  the  properties  enumerated  below; 

•  Hybrid  simulation  models:  discrete  and  continuous  together 

•  Effective  modeling  rather  than  physical  modeling 

•  HLA-based  distributed  simulation 

•  Includes  an  optimization  module 

•  Serves  a  base  for  data  fusion 

•  Analysis  for  both  tactical  and  training 
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OVERVIEW 

Endorsed  at  the  Washington  Summit,  confirmed  at  the  Prague  Summit,  the  Training  and 
Education  Enhancement  Programme  is  viewed  as  a  useful  tool  to  achieve  interoperability 
and  considerable  progress  has  been  made  in  several  areas  in  the  past  year,  especially  in 
its  Advanced  Distributed  Learning  and  Simulation  component.  A  number  of  studies  have 
been  completed  with  the  expertise  of  the  RTA/NMSG,  the  NATO  Training  Group  (NTG) 
and  others  in  support  of  NATO  Strategic  Commands,  with  Allied  Command  Transformation 
(ACT)  in  the  lead. 

The  ADL  prototype  is  considered  a  success  and  the  establishment  of  a  NATO/PfP  ADL 
capability  supporting  NATO/PfP  Education  and  Training  is  feasible.  ACT  has  been 
requested  to  propose  a  course  of  action  to  implement  it,  including  the  continuation  of  the 
prototype  use  with  National  contributions  until  a  Capability  Package  (CP)  is  developed. 

It  is  feasible  and  cost-effective  to  use  distributed  simulation  for  training.  ACT  has  been 
requested  to  propose  a  course  of  action  to  implement  it  through  the  execution  of  a  set  of 
distributed  NATO/PfP  prototype  exercises,  and  the  development  of  a  CP  including  a 
successor  of  Allied  Command  Europe  (ACE)  Command  and  Staff  Training  Programme 
(ACSTP). 

BACKGROUND 

The  December  1998  North  Atlantic  Treaty  Organisation  (NATO)  Ministerial  meetings 
tasked  the  North  Atlantic  Council  (NAC)  to  identify  and  consolidate  initiatives  underway  in 
Partnership  for  Peace  (PfP)  in  order  to  form  a  coherent  package  of  measures  to  reinforce 
PfP’s  operational  capabilities.  Education  and  training  activities  such  as  the  PfP  Training 
Centres,  the  PfP  Simulation  Network  and  the  PfP  Consortium  of  Defence  Academies  and 
Security  Studies  Institutes  were  identified  as  appropriate  subjects  for  consolidation. 

During  the  April  1999  NATO  Summit  in  Washington,  Heads  of  State  and  Government 
endorsed  the  resulting  PfP  Training  and  Education  Enhancement  Programme  (TEEP). 

The  TEEP  is  to  provide  a  structured  approach  to  optimise  and  improve  training  and 
education  in  the  Partnership  to  meet  the  current  and  future  demands  of  an  Enhanced  and 
More  Operational  Partnership  (EMOP),  focussing  specifically  on  the  achievement  of 
interoperability. 


Paper  presented  at  the  MSG-022/SY-003  Conference  on  “C3I  and  M&S  Interoperability" , 
held  in  Antalya,  Turkey,  9-10  October  2003,  and  published  in  RTO-MP-MSG-022. 

This  paper  reflects  the  author’s  personal  views  on  the  subject 
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The  TEEP  programme  was  re-endorsed  during  the  November  2002  NATO  Summit  in 
Prague,  where  the  Alliance  took  the  decision  to  upgrade  NATO  co-operation  with  the 
EAPC/PfP  countries  and  highlighted  the  requirement  to  continue  to  further  enhance 
NATO/  PfP  interoperability  as  part  of  the  transformation  agenda.  Critical  to  this  approach 
is  the  need  to  support  the  development  of  Combined  Joint  Task  Force  (CJTF) 
headquarters  and  to  expand  the  strategic  reach  of  the  co-operative  building  effort  to 
include  Central  Asia  and  the  Caucasus. 

The  TEEP  programme  encompasses  six  components: 

-  linkages  and  collaboration; 

-  feedback  and  assessment  mechanism; 

-  interoperablity; 

-  exercises; 

-  national  training  and  education  strategies; 

-  advanced  distributed  learning  &  simulation  (ADL). 

This  document  will  focus  on  the  latter  component  only. 

THE  VISION 

To  implement  Prague  Summit  mandates  in  strengthening  NATO-PfP  education  and 
training  collaboration  as  part  of  the  transformation  agenda,  it  is  essential  to  build  upon 
existing  efforts,  and  only  where  necessary  to  explore  the  need  to  establish  new  information 
technology  capabilities.  The  desired  long-term  end  state  vision  is  to  provide  Allies  and 
Partners  with  a  multinational  training  and  exercise  environment  up  to  the  CJTF  “command 
and  staff”  level,  supported  by  a  near-real-time  interactive  ADL  and  Simulation  environment 
that: 

-  Supports  combined,  joint  operations; 

-  Links  military,  political-military,  and  civil-military  components  into  simulation,  modelling 
and  training; 

-  and,  Integrates  such  distributed  training  with  focused  professional  military  education 
delivered  through  ADL. 

It  is  worth  noting  that  the  strengthening  of  NATO-PfP  education  and  training  not  only 
benefits  Partners,  but  also  NATO  Nations  and  the  Alliance  as  a  whole. 

The  studies  highlight  that  there  is  not  yet  a  single,  coherent  strategy  nor  an  implementation 
plan  that  links  and  co-ordinates  existing  key  agencies  within  NATO  and  PfP  to  achieve 
enhanced  interoperability  and  which  satisfies  NATO  and  Partner  requirements  for  training 
and  education  in  NATO-led,  Non-Article  5,  combined,  joint  operations  down  to  the  battalion 
level.  The  key  agencies,  infrastructure  and  processes  that  should  be  linked  and  co¬ 
ordinated  to  reach  those  objectives  are  illustrated  as  shown  at  the  figure  below: 


This  paper  reflects  the  author’s  personal  views  on  the  subject 
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Note:  IMS  International  Military  Staff;  SHAPE  Supreme  Headquarters  Allied  Powers  Europe;  SACLANT 


Supreme  Allied  Commander  Europe,  recently  renamed  ACT  Allied  Command  Transformation;  NS(S)  NATO 
School  (SHAPE)  recently  renamed  NATO  SHAPE  (Oberammergau);  NTG  NATO  Training  Group;PCC 
Partnership  Co-ordination  Cell 


The  Washington  Summit  TEEP-related  initiatives  of  PfP  Training  Centres,  PfP  Simulation 
Network  and  PfP  Consortium  of  Defence  Academies  and  Security  Studies  Institutes 
continue  to  form  an  interlocking  and  coherent  package  of  measures  to  reinforce  PfP’s 
operational  capabilities.  To  implement  Prague’s  direction  to  intensify  this  effort  in  support 
of  Transformation,  explicit  NATO  counterpart  efforts  need  to  be  identified  and  reinforced. 
Among  the  benefits  that  the  nations  may  expect  to  receive  in  return  from  this  collaboration 
with  NATO  is  higher  levels  of  interoperability,  including  the  capability  to  co-evolve 
organisation,  command  concepts  and  doctrine  among  the  many  nations  that  will  be 
sharing  advances  in  technology. 


The  figure  below  summarises  the  necessity  to  align  on-going  PfP  TEEP  activities  referred 
to  above  with  their  corresponding  NATO  counterpart:  a  NATO  Distributed  Simulation 
initiative,  NATO  School  (Oberammergau)  (NS(O)),  and  the  NATO  Defence  College  (NDC). 
In  addition  the  figure  highlights  the  needs  to  create  a  permanent  nucleus  at  ACT  to  co¬ 
ordinate  NATO-PfP  ADL  &  Simulation  efforts.  These  ideas  comprise  the  central  elements 
of  the  NATO-PfP  training  transformation  effort  that  can  be  supported  by  Advanced 
Distributed  Learning  and  Distributed  Simulation  capabilities.  Implementation  of  this  vision 
is  enabled  and  supported  by  the  links  established  with  the  TEEP-  related  Training  and 
Education  Initiatives,  which  have  been  instrumental  in  bringing  diverse  training  and 
education  communities  into  a  mutual  support  framework. 
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Mutual  Support  Activities 


A  MULTINATIONAL  ENVIRONMENT 

Since  their  establishment  at  the  April  1999  Washington  NATO-EAPC  Summit  as  “new 
tools”  in  support  of  NATO-PfP  interoperability,  the  PfP  Consortium  of  Defence  Academies 
and  Security  Studies  Institutes,  the  PfP  Simulation  Network,  and  PfP  Training  Centres 
have  flourished. 

As  “in  the  spirit”  of  PfP  activities,  they  have  benefited  from  the  convergence  of  national  and 
multinational  support,  while  remaining  free  from  subordination  to  any  particular  national 
agenda  or  direct  NATO  involvement.  Driven  largely  by  the  principle  of  voluntarism,  they 
provide  a  unique,  mutually  supporting  venue  for  concept  development  and 
experimentation.  Exploring  new  approaches  to  security  cooperation  and  interoperability, 
they  analyse  lessons  learned  and  help  to  share  best  practices. 

Consequently,  these  three  major  “tools”  of  TEEP  provide  a  foundation  for  NATO- 
PfPtraining  transformation,  consistent  with  PfP’s  principle  of  “self-differentiation,”  whereby 
nations  determine  for  themselves  what  they  wish  to  contribute  or  to  receive.  Collectively 
they  assist  in  the  development  of  a  cooperative  network  of  security  institutions. 

PfP  Consortium  of  Defence  Academies  and  Security  Studies  Institutes 

The  PfP  Consortium  constructs  new  tools  to  support  collaborative  learning  between 
nations  and  is  at  the  origin  of  NATO’s  own  capabilities  in  critical  transformation  areas.  It 
provides  a  unique  example  of  international  cooperation  in  the  multinational  development  of 
e-learning  applications  for  security  cooperation.  The  end  state  vision  of  a  virtual 
multinational  learning  environment  that  links  military,  political-military,  and  civil-military 
components  into  distributed  modelling  and  simulation  environment  supported  by  focused 
professional  military  education  is  a  realistic  goal  attainable  in  collaboration  with  the 
Consortium’s  core  ADL  development  capability. 

Switzerland’s  support  through  the  PfP  Consortium  has  been  a  critically  important  element. 
Swiss  teaming  arrangements  with  Allies  employing  the  ADL  Co-lab  SCORM  standard  was 
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the  principal  factor  in  the  development  of  technical  tools  and  learning  material  for 
NATO/PfP  ADL.  Switzerland  further  provided  the  leading  support  in  coordinating  and 
integrating  Voluntary  Contributions  by  joining  a  wide  array  of  PfP  Consortium  experts  from 
throughout  the  EAPC  region  through  the  PfP  Consortium’s  ADL,  Simulation  and  Curricula 
Working  Groups.  As  NATO  implements  the  Prague  Summit  mandate  for  EAPC-PfP 
activities,  an  essential  element  in  the  success  of  the  NATO-PfP  transformation  effort  will 
be  to  ensure  the  preservation  of  distinctive  Partner  nation  lead  roles  and  responsibilities 
and  align  them  in  a  corresponding  relationship  with  the  NATO  Defence  College. 

PfP  Training  Centres 

Nine  Allied  and  Partner  Nations  participate  in  providing  PfP  Training  Centres,  most  of 
whom  focus  on  operational  and  tactical  level  training  and  instruction  in  NATO/PfP  staff 
procedures  and  other  individual  skills.  NATO  has  a  link  to  them  through  the  NATO  School 
(Oberammergau),  and  they  agreed  in  their  last  Conference  of  Commandants  to  increase 
their  role  in  ADL  and  Simulation  development  in  support  of  enhanced  NATO/PfP 
Interoperability..  Increased  attention  to  advanced  distributed  learning  and  distributed 
simulation  shared  among  and  between  the  Centres  could  lead  to  new  synergies,  leverage 
and  multiply  the  use  of  scarce  resources,  and  produce  greater  operational  readiness  as 
part  of  an  enhanced  training  transformation  capability.  Transformation  of  courses  can  be 
usefully  supported  in  having  PfP  Training  Centres  and  Co-operative  Development  Teams 
work  together,  as  Turkey  plans  to  do,  for  instance. 

PfP  Training  Centres  are  assessed  to  be  an  essential  source  of  insight  and  guidance  on 
the  harmonization  of  curricula  and  could  help  in  developing  and  sharing  ADL  courses  and 
joining  in  Distributed  Simulation  Command  Post  Exercises  (CAX)  under  the  auspices  of 
the  PfP  Simulation  Network,  or  in  a  Distributed  Defence  and  Wargaming  Simulation 
approach  in  tandem  with  the  PfP  Consortium.  In  support  of  the  NATO-PfP  ADL  and 
Distributed  Simulation  effort,  NS(O)  could  be  strengthened  to  perform  a  ADL/SIM 
clearinghouse  function  among  the  PfP  Training  Centres  and  provide  another  mechanism 
for  including  Partner  nations  in  the  Transformation  agenda. 

PfP  Simulation  Network 

The  PfP  Simulation  Network  initiative  has  developed  on  a  regional-basis  (e.g.,  Southeast 
Europe  Simulation  Network  (SEESIM),  Baltic  Simulation  Network  (BALTSIM),  et  al), 
joining  in  mutual  collaboration  approximately  twenty  Nations.  Like  the  ADL  effort,  where 
one  Partner  nation  (Switzerland)  has  led  the  effort  in  mentoring  other  nations,  Sweden  has 
been  at  the  forefront  in  developing  and  promoting  Distributed  Simulation  as  a  core 
capability  connecting  Allies  and  Partners,  employing  in  particular  the  “Viking”  series  of 
exercises.  This  effort,  however,  is  not  presently  linked  with  any  NATO  permanent  office  to 
distribute  simulation  and  this  is  another  area  of  ongoing  activity  that  is  of  great  potential 
benefit  to  the  Allied  Command  for  Transformation. 

Transformation:  Building  Upon  Complementary  Efforts  to  Attain  New  Synergies 

The  Prague  Summit  Declaration  statement  concerning  cooperation  with  the  EAPC/PfP 
countries  directs  that  “Allies,  in  consultation  with  Partners,  will,  to  the  maximum  extent 
possible,  increase  involvement  of  Partners,  as  appropriate,  in  the  planning,  conduct,  and 
oversight  of  those  activities  and  projects  in  which  they  participate  and  to  which  they 
contribute.”  This  means  that  efforts  such  as  the  PfP  Consortium,  PfP  Training  Centres, 
and  PfP  Simulation  Network  may  benefit  of  greater  Partner  direction  and  control.  At  the 
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same  time,  a  strengthening  in  the  participation  and  linkage  of  NATO  counterpart  activities 
could  complement  the  integration  and  mutual  support  effort.  Respectively,  the  NATO 
Defence  College,  the  NATO  School  (Oberammergau),  and  the  NATO-PfP  Distributed 
Simulation  Capability  Initiative  (DSCI)  are  equally  important  in  the  overall  transformation 
vision  to  attain  new  synergies  in  the  quest  for  enhanced  interoperability  and  strengthened 
security  cooperation  throughout  the  Euro-Atlantic  region. 

MAIN  CONCLUSIONS 

On  Advanced  Distributed  Learning: 

ADL  capability  has  enormous  potential.  The  NATO  /  PfP  ADL  Program  can  contribute  to 
further  increasing  readiness  by  providing  high  quality,  interoperable,  and  sharable 
education  and  training  anytime  and  anywhere,  while  improving  military  effectiveness  and 
efficiency.  ADL  might  become  a  prerequisite  to  attending  a  course,  thus  ensuring  the 
proper  level  of  training  has  been  reached  by  the  trainees.  The  Sharable  Courseware 
Object  Reference  Model  (SCORM)  concept  provides  a  basis  for  the  development  of  ADL 
modules  to  be  freely  shared  among  institutions  and  nations  in  support  of  interoperability 
and  reusability.  The  NATO/PfP  ADL  prototype  has  provided  an  immediate  ADL  capability 
to  NATO  and  PfP  nations,  resourced  by  Voluntary  National  Contributions  (VNCs).  In 
particular,  the  “Introduction  to  NATO”  -  the  first  course  in  the  prototype  -  has  been 
considered  by  users  as  useful,  well  prepared,  and  an  excellent  way  to  introduce,  refresh  or 
update  students  on  that  subject.  In  general  the  ADL  Prototype  has  been  assessed  as 
easy  to  use  and  valuable;  moreover,  there  is  a  strong  request  for  the  provision  of  more 
courses.  The  establishment  of  a  permanent  Operational  NATO/  PfP  ADL  capability 
supporting  PfP  and  also  NATO  education  and  training  is  feasible.The  ADL  prototype 
should  be  extended,  resourced  by  VNCs,  to  form  an  Initial  Operational  Capability  that  will 
continue  providing  an  immediate  ADL  capability  and  service  to  NATO  and  PfP  nations, 
and  will  form  the  basis  for  specifying  the  procurement,  via  standard  NATO  Capability 
Package  procedures,  of  an  Operational  NATO/PfP  ADL  Capability. 

To  meet  the  request  for  new  ADL  material  the  national  Co-operative  Development  Teams 
(CDT),  trained  under  the  auspices  of  US-Swiss  support  to  the  PfP  Consortium  of  Defence 
Academies,  have  to  continue  their  crucial  activity  of  transforming  traditional  courses  into 
ADL  supported  courses.  It  is  also  anticipated  that  NATO  and  PfP  Educational  Institutes 
should  become  producers  of  ADL  courses  and  material. There  is  a  need  to  enhance  the 
ADL  capability  of  NATO  education  and  training  organisations.  The  establishment  of  ADL 
’’Chairs”  in  NDC  and  NS  (O),  as  well  as  one  Co-operative  Development  Team  for  both 
Institutions  are  key  factors  to  harmonise  ADL  work  and  populate  their  portal.  This 
capability  should  be  provided  as  part  of  a  new  VNC  in  terms  of  the  provision  of  qualified 
technical  personnel  in  support  of  PSE’s  devoted  to  TEEP  ADL/SIM  implementation,  with 
equal  contributions  from  both  Allies  and  Partners.The  future  Operational  ADL  capability  for 
NATO/PfP  Education  and  Training  should  be  located  at  ACT  and  supported  by  NATO 
Education  Institutes  (NDC,  NS  (O),  NCISS),  PfP  Training  Centres  and  the  PfP  Consortium 
of  Defence  Academies.  The  training  provided  by  these  institutions  and  their  requirements 
varies  considerably,  and  it  is  more  effective  to  achieve  ADL  capability  by  establishing  each 
of  these  organisations  and  PTCs  as  “Centres  of  Excellence”  in  NATO/PfP  ADL. 
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Development  and  administration  of  a  common  knowledge  portal,  will  be  a  continuous 
requirement. 

The  continuing  use  of  Voluntary  Contributions  is  assessed  as  being  instrumental  for 
success  until  a  clear  definition  of  a  capability  package  (CP)  can  be  made  for  ADL  and 
Simulation.  Contributors  in  the  development  of  the  ADL  prototype  deserving  a  particular 
mention  are: 

The  PfP  Consortium  of  Defence  Academies  and  Studies  Institutes  that  delivered,  through 
support  provided  by  Switzerland  and  the  US  ADL  Co-lab  (employing  the  SCORM 
standard),  the  technical  tools  for  the  highly  successful  NATO/PfP  ADL  Prototype. 
Switzerland  whose  wider  involvement  through  its  support  to  the  PfP  Consortium  of 
Defence  Academies  has  been  a  critically  important  element  in  the  NATO-PfP  ADL  success 
story. 

A  permanent  establishment  of  a  NATO-PfP  ADL  Advisory  Board  should  be  a  priority  task, 
with  relevant  NATO  educational  and  training  institutions  drawn  into  a  supporting 
framework  with  TEEP  PfP  activities,  as  well  as  with  key  National  representatives  who  may 
be  involved  in  providing  Voluntary  National  Contributions.  Allied  Command  for 
Transformation  should  develop  and  co-ordinate  appropriate  terms  of  reference  for  MC 
endorsement. 

It  is  also  noted  that  some  of  the  PfP  countries  do  not  yet  have  the  desired  level  of  Internet 
access,  particularly  in  the  Caucasus  and  Central  Asia.  It  has  been  identified  that  this 
concern  might  be  met  in  using  the  Virtual  Silk  Highway  Project.  Collaboration  with  the 
Virtual  Silk  Highway  Project  through  the  National  Research  and  Education  Network,  as 
well  as  exchange  of  information  between  the  IMS  and  the  IS  Public  Diplomacy  Division 
should  therefore  be  continued. 

On  Modelling  and  Distributed  Simulation: 

There  is  a  requirement,  expressed  by  PfP  Nations,  for  NATO  to  sponsor  a  formal 
programme  that  assists  Partners  to  facilitate  their  capability  to  participate  in  NATO-led, 
Non-Article  5  operations.  The  envisioned  programme  will  provide  training  and  education 
up  to  and  including  in  a  Combined  Joint  Task  Force  (CJTF)  staff.  This  will  benefit  NATO 
as  well. 

It  is  technically  feasible  and  highly  desirable  to  meet  this  requirement  through  the  conduct 
of  NATO-led,  combined  joint  exercises  using  distributed  CAX  and  associated  ADL  to  a  key 
number  of  PfP  Staffs  and  Simulation  Centres. 

NATO  does  not  currently  have  an  exercise  programme  which  is  sufficiently 
comprehensive  to  provide  the  opportunities  or  infrastructure  as  stated  above. 

A  formal  phased  NATO/PfP  ADL  and  Simulation  programme  could  be  implemented  by 
integrating  existing  NATO  resources  with  additional  identified  VNCs,  which  will  provide 
cost-effective  training  opportunities  for  Partners  to  develop  and  practice  NATO-PfP 
Interoperability  for  combined  and  joint  operations  using  distributed  CAXs,  with  ACT  being 
in  best  position  to  provide  oversight. 
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ACT,  as  the  Allied  Command  for  Transformation,  with  the  support  of  NATO  Education 
Institutions,  such  as  NDC,  NS  (O),  and  NCSIS,  is  best  suited  to  be  responsible  for  the 
creation  and  maintenance  of  the  overall  NATO-PfP  Training  and  Education  Programme, 
including  ADL  and  Simulation  efforts. 

Experience  gained  during  the  development  of  the  first  phase  of  that  NATO-PfP  Training 
Programme  could  form  the  basis  for  ACT  to  specify  the  procurement,  via  standard  NATO 
procedures,  of  an  Operational  Capability  for  NATO  and  PfP  which  integrates  NATO/  PfP 
Distributed  Simulation  to  a  future  Leadership  Staff  Training  Programme  (successor  of 
ACSTP). 

On  the  links  between  NATO  and  the  PfP  Consortium  of  Defence  Academies: 

A  recommendation  on  the  revision  and  strengthening  of  this  link  will  form  part  of  the 
Progress  Report  on  TEEP  that  will  be  provided  as  NMA  advice  in  the  framework  of  the 
preparation  of  the  Spring  Ministerial. 

The  NDC  role  as  NATO’s  focus  with  the  PfP  Consortium  has  proven  useful  in  keeping 
NATO  apprised  of  the  activities  of  the  Consortium.  NDC’s  active  involvement  in 
participating  in  numerous  working  groups,  in  particular  the  Secretariat  Working  Group,  has 
likewise  helped  the  Consortium.  NDC  should  continue  to  represent  NATO  in  any 
deliberations  concerning  the  evolution  of  the  Consortium,  especially  in  regard  to  the 
NATO-PfP  interface  on  educational  and  research  requirements. 

The  NDC,  in  collaboration  with  the  PfP  Consortium  of  Defence  Academies,  should  become 
responsible  for  ADL  course  contents  at  the  strategic  and  political-military  education  level, 
as  depicted  below: 


PfP  Consortium  and  NA  TO 


PfP  Consortium 


Official  NATO 
Relation 
ADL  node 


On  the  links  between  NATO  and  the  PfP  Training  Centres: 

The  NS  (O)  in  collaboration  with  PfP  Training  Centres  should  become  responsible  for  ADL 
course  contents  at  the  military  operational  training  level. 
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The  NS  (O)  role  in  relationship  to  PfP  Training  Centres  should  be  strengthened  with  the 
view  to  facilitate  the  integration  of  operational  training  and  educational  requirements  in 
support  of  ACT  (Allied  Command  for  Transformation). 


The  PfP  Training  Centres  are  assessed  to  be  an  ideal  source  of  insight  and  guidance  on 
the  harmonisation  of  curricula  and  producers  of  ADL  material. 

PfP  Simulation  Centers  and  NATO 


Official  NATO 
Relation 
SIMNET& 
ADL  node 


On  the  links  between  NATO  and  the  PfP  Simulation  Network: 

Allied  Command  for  Transformation  (ACT)  should  establish  a  NATO-PfP  Distributed 
Simulation  Capability  Initiative  (DSCI)  and  a  Programme  Office  to  be  responsible  for 
Distributed  Simulation  issues  at  both  the  strategic  and  operational  level.  DSCI  should 
integrates  NATO/  PfP  Distributed  Simulation  to  a  future  Leadership  Staff  Training 
Programme  (successor  of  ACSTP) 

The  ACT  DSCI  office  should  work  in  collaboration  with  the  NDC  and  the  PfP  Consortium  in 
exploring  opportunities  to  strengthen  defence  gaming  and  simulation  capabilities  at  the 
strategic  level. 

The  ACT  DSCI  office  should  work  in  collaboration  with  the  NS  (O)  and  the  PfP  Training 
Centres  in  exploring  opportunities  to  strengthen  distributed  simulation  capabilities  at  the 
operational  level  in  support  of  the  CJTF  concept. 

The  figure  below  shows  how  the  Simulation  Centres  might  be  interlinked  with  NATO. 
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NA  TO-PfP  Simnet 


On  the  structure: 

ACT  should  become  the  single  focus  for  NATO  and  PfP  ADL  and  Simulation  in  NATO  and 
responsible  for  the  creation  and  maintenance  of  the  NATO-PfP  Training  and  Education 
Programme,  maintaining  a  close  collaboration  with  SHAPE. 

ACT  should  establish  a  core  capability  to  implement  the  ADL  strategy  and  to  provide 
guidance  in  Distributed  Learning  and  Simulation  and  to  be  the  permanent  organisation  to 
administer,  manage  and  co-ordinate  ADL  &  Distributed  Simulation  in  NATO  and 
harmonise  with  PfP  Nations  and  PfP  Training  Centres. 

The  key  agencies,  infrastructure  and  processes  might  be  interlinked  as  follows: 


Mutual  Support  Activities 
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WAY  AHEAD 


On  Advanced  Distributed  Learning. 

The  ADL  prototype  established  under  ACT  has  been  evaluated  throughout  2002  thanks  to 
National  Contributions  from  Allies  and  Partners,  and  with  the  continuous  support  of 
RTA/NMSG.  It  has  been  concluded  that  the  prototype  is  valid,  and  NATO  therefore 
recommended  the  development  of  a  permanent  TEEP  ADL  capability  in  support  of 
NATO/PfP  Education  and  Training. 

ACT  and  SHAPE  have  been  requested  to  make  proposals  regarding  the  development  of  a 
capability  package  by  Spring  2004,  that  could  be  implemented  mainly  through  the 
continuation  of  current  VNCs. 

On  Modelling  and  Simulation. 

ACT  and  SHAPE  analysis  concluded  distributed  simulation  has  an  important  potential  to 
facilitate  the  training  of  staffs,  up  to  CJTF  level  and  to  contribute  enhancing  interoperability 
at  lower  operating  costs.  Currently,  a  number  of  national  realisations,  such  as  VIKING, 
BALTSIM  or  SEESIM  exercises  could  meet  PfP  requirements  up  to  multinational  brigade 
level.  However  there  are  no  existing  opportunities  at  the  Component  Command  and  CJTF 
levels. 

Establishing  a  complete  NATO/PfP  simulation  capability  at  all  training  levels  would  go  far 
beyond  NATO’s  investment  capabilities.  Therefore,  existing  national  realisations  should  be 
used  through  specific  agreements.  To  this  end,  as  a  trial,  NATO  will  be  represented  in  the 
next  VIKING  exercise  in  December  2003. 

NATO  could  concentrate  on  the  establishment  of  a  specific  simulation  capability  at  the 
CJTF  level,  and  support  lower  operational  levels.  It  has  been  assessed  that  such  a 
capability  should  be  feasible  and  affordable. 

ACT  and  SHAPE  have  been  requested  to  make  proposals  regarding  the  development  of  a 
capability  package,  together  with  a  set  of  distributed  NATO  prototype  exercises  by  Spring 
2004. 


CONCLUSION 

Considerable  interest  has  been  addressed  to  TEEP  since  the  Washington  Summit.  The 
Prague  Summit,  known  as  the  “Capabilities  Summit”  paved  the  way  for  implementing  the 
programme,  in  re-endorsing  it. 

The  International  Military  Staff  has  now  nearly  completed  the  policy  part  of  the  work, 
thanks  to  the  contribution  of  a  team  of  many  NATO  and  Partners  individual  and  bodies, 
of  which  ACT,  the  NDC,  the  NS(O),  the  US  JFCOM,  the  Swedish  Wargaming  Centre,  the 
RTA/NMSG  and  the  International  Staff  contributions  have  been  instrumental  for  success. 

ACT  and  SHAPE  are  currently  devoting  considerable  efforts  in  developing  capability 
packages  for  ADL  and  for  Simulation  sub-components,  so  that  this  becomes  reality. 

They  can  only  have  success  if  real  commitments  are  decided  between  NATO,  PfP, 
regional  and  national  contributions. 
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RESUME 

Le  deploiement  en  cours  du  SIR,  Systeme  d  ’Information  Regimentaire  (SIR)  destine  a  couvrir  a  la  fois  le 
niveau  regimentaire  (Bataillon)  et  unite  elementaire  (Compagnie),  implique  de  revoir  rapidement  les 
methodes  de  formation  et  d’entrainement.  En  effet,  les  exercices  d’entrainement  actuels  et  les 
architectures  de  CAX  ne  sont  plus  adaptes,  puisqu  ’ils  ne  prennent  pas  en  consideration  la  valeur  ajoutee 
apportee  par  les  systemes  C4I.  Ils  ne  permettent  pas,  par  exemple,  de  stimuler  le  SIR  avec  des  donnees 
appropriees  pour  le  C4I.  ESTHER,  acronyme  pour  "Environnement  Synthetique  de  THeatre  pour 
I’Entrainement  des  PC  Regimentaires",  est  un  Programme  d’ Etude  Amont  (PEA)  pilote par  la  DGA.  II  a 
pour  objectif  d’etudier  la  faisabilite  de  doter  I’armee  de  terre  d'une  structure  d’accueil  de  type  plug-in 
permettant  la  connexion  nationale  et  multinationale  de  C4I  et  de  systemes  de  simulation  HLA  distribues  et 
offrant  des  sendees  pour  la  preparation,  Texecution  et  V analyse  des  exercices  d’entrainement.  Pour  le 
PEA  ESTHER,  T exigence  primordiale  de  I’armee  de  terre  consiste  a  faire  communiquer  entre  eux  les 
modeles  de  simulation  existants  et  les  C4I  actuellement  deployes,  pour  satisfaire  ses  besoins  de  formation 
et  d’entrainement.  ESTHER  s’ attache  done  particulierement  a  l  ’  interoperability  entre  le  SIR  et  JANUS 
HLA.  Des  resultats  convaincants  out  d’ores  et  deja  etc  obtenus  dans  le  domaine  de  T interoperability  entre 
C4I  et  systemes  de  simulation,  aborde  selon  l  ’approche  en  deux  etapes  suivante  : 

•  La  premiere  etape  concerne  la  configuration  des  systemes  de  simulation  et  des  C4I  avant  leur 
deploiement  et  leur  utilisation.  Cette  etape  comprend  l ’identification  et  la  mise  a  disposition  des 
donnees  pertinentes  a  partager,  permettant  ainsi  d'assurer  I’interoperabilite  dite  statique.  Dans  le 
domaine  operationnel,  les  donnees  statiques  telles  que  I’ordre  de  bataille,  la  position  initiale  des 
unites  et  leurs  ressources,  les  reseaux  de  communication  tactique  et  les  lignes  de  coordination  doivent 
etre  identiques  pour  les  deux  types  de  systemes.  Dans  le  domaine  technique,  l ’interoperability 
statique  concerne  la  configuration  du  temps  de  reference,  les  adresses  de  messagerie  des  C41,  les 
adresses  IP  des  systemes  informatiques,  les  fichiers  de  configuration  des  federes  et  des  routeurs. 
Actuellement,  les  donnees  statiques  du  domaine  operationnel  sont  disseminees  entre  les  systemes  de 
simulation  et  les  C4I,  et  l' initialisation  de  ces  derniers  implique  un  processus  de  distribution  selectif. 
Jusqu  ’a  present,  les  systemes  de  simulation  et  les  C4I  ont  etc  conqus  selon  des  filieres  bien  separees. 
Leurs  standards  d’echange  respectifs  ne  sont  pas  compatibles,  ce  qui  impose  la  replication  manuelle 
de  l ’information  d’un  systeme  a  un  autre.  Ces  operations  prennent  du  temps,  consomment  de  la 
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ressource  et  introduisent  des  risques  d’erreurs  dues  a  de  mauvaises  interpretations.  Des  mecanismes 
doivent  done  etre  mis  en  place  pour  automatiser  la  configuration  commune  des  systemes  de  simulation 
et  des  C4I. 

•  La  seconde  etape  concerne  la  connexion  bidirectionnelle  et  la  coordination  entre  systemes  de 
simulation  et  C4I  durant  l ’execution  de  la  federation,  permettant  ainsi  d' assurer  I’interoperabilite  dite 
dynamique.  Du  point  de  vue  operationnel,  cela  signifie  que  les  C4I  doivent  pouvoir  emettre  des 
ordres  aux  unites  subordonnees  (i.e.  unites  simulees)  et  recevoir  en  retour  leurs  comptes-rendus  issus 
de  Venvironnement  simule  (position  des  subordonnes,  etat  des  mines,  donnees  logistiques,  ...).  Cela 
signifie  egalement  que  les  activites  des  deux  systemes  doivent  pouvoir  etre  controlees  et 
synchronisees.  D’un point  de  vue  technique,  I’interoperabilite  dynamique  impose  une  comprehension 
commune  du  champ  de  bataille  numerise  afin  de  disposer  d’une  information  coherente,  et  l ’utilisation 
de  standards  d’echange  identiques  pour  la  communication  de  l  'information  entre  ces  systemes.  Le 
modele  de  donnees  des  C4I  et  les  modeles  de  donnees  des  systemes  de  simulation  (et  de  la  federation) 
doivent  converger,  ou  au  moins  se  recouvrir  partiellement,  faute  de  quoi  l  ’interoperability  n  ’est  pas 
envisageable.  Aujourd’hui,  des  passerelles  sont  utilisees  pour  traduire  et  mettre  en  correspondance 
l  ’information  entre  les  systemes.  Cependant,  ces  passerelles  sont  congues  pour  fonctionner  dans  un 
environnement  determine  et  doivent  en  outre  suivre  les  evolutions  des  C4I.  C’est  pourquoi  au-dela  de 
I’alignement  des  modeles  de  donnees,  il  semble  indispensable  pour  I'avenir  d ’aligner  egalement  les 
architectures  en  partageant  des  modules  communs. 

Ce  "papier" presente  dans  le  detail  les  difficultes  introduites  ci-dessus,  il  dealt  les  solutions  telles  qu'elles 
out  etc  implementees  dans  ESTHER,  puis  il  propose  un  apergu  des  prochains  travaux  qui  seront 
accomplis  dans  la  suite  du  PEA  dans  le  domaine  de  l  ’interoperability  entre  systemes  de  simulation  et  C4I. 
La  presentation  s’acheve  avec  une  synthese  du  retour  d’experience  de  I’exercice  DEFTEMP  conduit  a 
l  ’EAI  en  mai  2003. 

OVERVIEW 

The  newly  fielded  French  Regimental  Information  System  (SIR),  covering  both  Battle  group  (Battalion 
Level)  and  Elementary  units  (Company  Level),  urgently  requires  an  improvement  to  the  current  education 
and  training  methods.  Previous  training  courses  and  CAX  architectures  are  no  longer  suitable  as  they  do 
not  take  into  account  the  added  value  provided  by  C4I  systems.  They  do  not  stimulate  SIR  with 
appropriate  C4I  data.  ESTHER  (Acronym  for  "Environnement  Synthetique  de  THeatre  pour 
I’Entrainement  des  PC  Regimentaire")  is  a  French  MoD  R&T program.  It  is  dedicated  to  exploring  the 
feasibility  of  providing  the  French  Army  with  a  plug-in  framework  allowing  national  and  nation-wide 
connections  of  distributed  C4I  and  HLA  Simulations  and  offering  services  to  achieve  preparation, 
execution  and  analysis  of  training  courses.  The  highest  priority  Army  requirement  is  for  ESTHER  to 
bridge  the  gap  between  the  legacy  Modelling  and  Simulation  tools  and  fielded  C4I  systems  to  support 
Army  education  and  training  activities.  Moreover,  ESTHER  addresses  the  interoperability  between  SIR 
and  JANUS  HLA.  Beneficial  results  have  been  obtained  in  the  area  of  M&S  and  C4I  interoperability 
according  to  the  two-stage  approach  below: 

•  The  first  stage  is  the  configuration  of  M&S  and  C4I  systems  prior  to  their  deployment  and  common 
use.  This  stage  covers  the  identification  of  the  relevant,  shared  data  and  distribution.  This  is  called 
static  interoperability.  In  the  operational  area,  static  data  like  order  of  battle,  terrain,  initial  units 
location  &  resources,  tactical  communication  network  and  operational  limits  have  to  be  consistent  in 
both  systems.  In  the  technical  area,  static  data  covers  the  configuration  of  reference  time,  C4I  Mail 
addresses,  systems  IP  addresses,  network  masks,  RTI  (rid  file)  and  routers.  Currently,  the  operational 
static  data  are  shared  out  between  M&S  and  C4I  systems  and  their  initialisation  imposes  a  selective 
distribution.  Up  to  now,  as  M&S  and  C4I  were  developed  along  separate  tracks,  interchange 
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standards  are  not  compatible.  This  usually  forces  manual  replication  of  information  from  one  system 
to  another.  Those  operations  are  time  and  resource  consuming  and  introduce  risks  of  errors  due  to 
wrong  interpretation.  Thus,  mechanisms  have  to  be  developed  to  automate  the  common  configuration 
of  M&S  and  C4I  systems  with  appropriate  data. 

•  The  second  stage  concerns  the  bi-directional  connection  and  the  co-ordination  between  M&S  and  C4I 
systems  during  the  federation  and  C4I  execution.  This  is  called  dynamic  interoperability.  From  the 
operational  point  of  view,  it  means  providing  the  capability  for  C4I  to  send  orders  to  its  subordinate 
units  (i.e.  simulated  units)  and  to  receive  reports  from  the  M&S  world  (subordinates  location, 
minefields  status,  logistic  data  etc.).  It  also  means  providing  control  and  synchronisation  of  both 
systems  activities.  From  the  technical  perspective,  dynamic  interoperability  implies  a  common 
understanding  of  the  digital  battle  space  in  order  to  handle  the  information  consistently,  and  the  use 
of  the  same  interchange  standard  to  cany  the  information  between  both  systems.  The  C4I  Data  Model 
and  the  Simulation/Federation  Object  Model  must  converge,  or  at  least  partially  overlap,  otherwise 
no  interoperability  could  take  place.  Currently,  gateways  are  used  to  translate  and  map  the 
information  between  systems.  However,  those  systems  are  made  to  run  in  a  limited  environment  and 
must  cope  with  the  improvements  of  the  legacy  C4I.  That  is  why,  beyond  the  alignment  of  data  models, 
it  appears  mandatory >  in  the  future  to  align  the  architecture  by  sharing  a  common  structure. 

The  paper  describes  in  more  details  the  issues  introduced  above,  depicts  the  current  solutions 
implemented  in  ESTHER  and  gives  an  insight  into  the  next  ESTHER  M&S  and  C4I  interoperability 
studies.  It  concludes  with  the  lessons  learnt  from  the  DEFTEMP  Exercise  held  at  EAI  (Ecole 
d ’Application  de  I’lnfanterie)  in  May  2003. 

1.0  INTRODUCTION  -  BACKGROUND 

1.1  SIR  overview 

The  SIR  (Regimental  Information  system)  is  the  French  Army  C4I  covering  both  Battalion  and  Company 
levels.  This  information  system  equips  Army  Combat,  Combat  Support  (Engineering  and  Artillery)  and 
Combat  Service  Support  (Logistics)  units. 

It  is  interconnected  with  the  following  French  Army  C4I  systems  : 

•  SICF  (Communication  &  Information  system  of  the  forces)  which  operationally  equips  the  Army 
Brigade  and  Division  levels, 

•  the  LECLERC  information  system  already  fielded, 

•  ATLAS  (Automation  of  Fire  and  Connections  of  Ground-to-ground  Artillery)  which  will  replace  in 
the  short  term  the  current  system  ATILA  for  the  artillery  chain, 

•  the  future  SIT  (Terminal  Information  System)  which  will  equip  all  the  army  units  at  section  level  in 
2008. 

The  communication  between  the  previous  systems  is  based  on  the  SICAT  Army  electronic  message 
format  and  the  XL  message  text  format.  Communication  networks  within  the  SIR  are  ensured  through  the 
PR4G  (Radio  Set  4th  Generation). 

The  SIR  is  mainly  installed  in  the  VAB  (Forward  Armoured  Vehicle)  with  a  single  or  a  double 
workstation  configuration. 

1.2  Training  and  Education  with  SIR 

The  newly  fielded  SIR  requires  an  improvement  to  the  current  education  and  training  methods  for  the 
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personnel  of  the  Command  Post  (CP).  It  is  indeed  necessary  to  take  into  account  the  added  value  of  the 
system  on  the  command  process.  Mentality  will  have  to  evolve  to  substitute  data  processing  for  the  paper 
map  to  support  the  decision  making  process. 

Du  to  the  amount  of  information  to  be  handled,  it  is  not  easy  to  create  an  attractive  education  course  for 
the  pupils.  The  first  SIR  education  courses  are  relatively  academic  and  theoretical,  in  order  to  give  a  good 
vision  on  the  wide  spectrum  of  the  system.  However,  the  SIR  pupils  key  concerns  are  obviously  the 
tactics,  and  it  is  difficult  to  demonstrate  the  SIR  added  value  on  the  command  process  with  a  "static"  or 
low  interactive  education  course. 

The  SIR  training  issue  is  a  stumbling  block  as  this  system  is  perceived  by  the  users  as  a  constraint  due  to 
the  amount  of  information  that  have  to  be  introduced  during  an  engagement.  CP  officers  are  reluctant  to 
use  it  because  the  system  changes  their  current  habits  and  seems  to  add  workload. 

Thus,  both  for  education  courses  and  training  exercises  purposes,  it  appears  mandatory  to  propose  to  the 
SIR  pupils  or  trainees  a  tactical  environment  as  realistic  as  possible  allowing  the  automatic  "stimulation" 
of  the  SIR. 

NB:  the  use  of  the  SIR  will  probably  never  replace  voice  communications,  particularly  important  and 
critical  during  the  combat. 

1.3  SIR  Usability 

The  tasks  to  be  achieved  at  CP  level  are  schematically  the  following  : 

•  Reception  and  processing  of  Operation  Orders  (OPO)  and  Fragmental  Orders  (FRAGO)  from  the 
superior, 

•  Generation  and  transmission  of  OPO  and  FRAGO  to  the  subordinates, 

•  Generation  of  requests  for  information  to  the  subordinates, 

•  Reception  of  the  Reports  from  the  subordinates, 

•  Update  of  the  Operational  Picture, 

•  Generation  and  transmission  of  the  reports  to  the  superior. 

These  tasks  could  be  achieved  more  effectively  with  the  use  of  the  SIR.  Are  not  software  Copy  and  Paste 
the  most  common  used  functions  as  they  help  saving  time  ?  Before  reaching  this  point,  it  is  necessary  that 
the  officers  gain  enough  confidence  in  the  system  to  decide  to  move  from  the  paper  maps  to  the  computer. 

1.4  SIR  Stimulation  objectives 

The  aim  of  the  battlefield  digitisation  allowed  by  the  C4I  chain  is  to  automatically  feed  each  C4I  system  at 
any  level  with  information  coming  from  subordinate  units,  reducing  the  tiresome  activities  related  to 
operational  picture  building  and  allowing  each  commanding  level  to  concentrate  on  operational 
capabilities. 

In  the  SIR  training  and  education  area,  the  stimulation  allows  to  initialise  the  data  flow,  populating  the  C4I 
system  at  Company  level  with  information  from  the  synthetic  forces  in  JANUS.  The  reduction  of  this 
tiresome  activities  previously  devoted  to  the  SIR  pupils  or  trainees,  allows  them  to  focus  on  the 
operational  capabilities  (operational  message  system,  operational  picture  management,  and  information 
management)  Hence,  they  have  more  time  available  for  tactical  tasks  (analyse  the  information,  take 
decision  and  send  appropriate  orders).  They  can  discover  the  added  value  of  the  C4I  system,  gain 
confidence  and  get  convinced  time  after  time  to  move  from  paper  and  manual  tasks  to  computer. 

This  concept  of  stimulation  implies  to  address  the  issue  of  C4I- Simulation  interoperability  detailed  in 
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2.0  C4I-SIMULATION  INTEROPERABILITY  ISSUE 

Various  approaches  were  proposed  to  conceptualise  the  C4I-Simulation  interoperability  issues.  The 
approach  retained  within  ESTHER  covers  two  stages: 

•  Static  interoperability  which  deals  with  the  configuration  of  both  systems  before  execution, 

•  Dynamic  interoperability,  which  deals  with  the  bi-directional  connection  between  the  C4I  and 
simulation  systems  and  with  their  co-ordination,  during  run  time. 

This  approach  is  presented  below  for  C4I-Simulation  interoperability  in  general,  before  being  instantiated 
for  the  particular  SIR  &  JANUS  case  in  section  3.0. 

2.1  Static  interoperability 

This  stage  consists  in  configuring  the  simulation  and  C4I  systems  before  execution.  Relevant  (technical 
and  operational)  data  have  to  be  identified,  shared  and  appropriately  distributed  to  each  system. 

2.1.1  Data  Identification 

In  the  operational  area,  the  initial  configuration  data  shared  and  needed  by  C4I  and  simulation  systems 
are  as  follows: 

•  The  Terrain:  It  includes  data  relating  to  the  theatre  of  operation.  The  availability  of  data  bases  is  a 
first  issue.  However,  it  is  much  more  a  financial  and  calendar  concern  than  a  technical  one.  In  fact, 
different  sources  and  data  formats  are  available  as  well  as  editors  to  modify  such  data.  The 
consistency  is  a  second  issue.  Terrain  data  must  be  consistent  even  if  the  aggregation  level  of  the  data 
handled  by  the  two  systems  are  different.  As  an  example,  elevation  and  planimetry  must  be  the  same 
whatever  the  systems  so  that  the  line  of  sight  function  provides  consistent  results. 

•  The  Order  of  Battle  (ORB AT):  This  is  the  organisation  of  the  fielded  friendly  and  opposite  forces, 
with  different  representations  according  to  the  C4I  and  simulation  needs.  On  the  C4I  side,  the 
representation  must  be  compliant  with  the  hierarchical  organisation.  In  addition,  the  naming 
conventions  and  the  operational  symbolic  are  very  important.  The  ORBAT  may  evolve  during  the 
engagement  with  possible  reinforcements,  and  must  be  displayed  with  an  aggregation  level  consistent 
with  the  CP  level  in  the  hierarchy.  On  the  simulation  side,  the  key  point  is  to  define  an  organisation 
allowing  the  creation  of  simulated  units,  their  characterisation  with  physical,  dynamic  and  behavioural 
models,  their  assignment  to  the  simulation  operators.  If  every  forces  and  units  must  be  defined  on 
simulation  side,  it  is  not  mandatory  on  C4I  side.  The  discovery  of  unknown  units  may  happen  in  real 
time  and  must  be  identified  on  case  to  case  as  single  elements  out  of  the  conventional  ORBAT. 

•  Tactical  information:  Initial  information  comes  from  the  OPO:  co-ordination  lines,  reports  lines, 
forbidden  areas  etc.  These  data  constitute  guidelines  which  must  be  consistent  between  C4I  and 
simulation  systems  in  order  to  prevent  misunderstanding  between  pupils/  trainees  and  subordinates 
managing  simulation  units.  Initial  information  deals  only  with  the  friendly  forces.  Information  relating 
to  the  opposite  forces  is  an  assumption  of  the  enemy  mission,  strength  or  location.  The  consistency 
between  C4I  and  simulation  is  required  but  not  mandatory. 

•  The  initial  situation:  This  defines  the  initial  location  of  friendly  units,  and  their  first  stages  of 
displacement.  The  accuracy  of  the  location  is  not  essential  for  C4I  which  usually  displays  aggregation 
of  units,  but  is  mandatory  on  the  simulation  side  which  must  also  include  all  the  data  describing  the 
friendly  and  the  opposite  forces.  Lastly,  an  initial  planning  of  the  displacements  for  the  units  can  be 
defined  before  the  beginning  of  the  run,  in  order  to  speed  up  the  exercise  launching  phase. 

•  Initial  Resources:  This  part  deals  with  Combat  Service  Support  (human  and  material  supplies  as 
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food,  ammunitions,  fuel,  etc).  Initial  resources  must  be  consistent  between  C4I  and  simulation 
systems.  From  the  C4I  point  of  view,  this  information  is  managed  inside  logistics  arrays  to  request 
supplies  when  the  limit  of  the  consumption  is  reached.  On  simulation  side,  these  data  are  mandatory 
for  the  models  and  to  generate  relevant  reports  towards  the  C4I  (See  §2.2). 

•  Tactical  Communication  Networks:  The  realism  of  the  tactical  communication  network  is  more  and 
more  requested  from  military  personals  for  training  purposes.  Operational  and  physical  characteristics 
of  communication  networks  for  data  transmission  must  be  taking  into  account.  As  an  example,  the 
organisation  of  the  network  with  relay  elements,  range,  frequencies  and  status  of  operational  devices, 
the  conditions  of  propagation,  must  be  modelled.  Units  equipped  with  C4I  systems  have  to  be 
identified  in  the  simulation.  At  the  end,  the  simulation  must  shared  with  the  C4I  system  the  network 
topology,  the  users  and  operational  addresses. 

•  Mailing  system:  Exchange  of  operational  messages  are  usually  performed  via  a  mailing  system.  It  is 
mandatory  to  share  the  operational  user  directory  between  C4I  and  simulation. 

In  the  technical  area,  the  initial  configuration  data  shared  and  needed  by  C4I  and  simulation  systems 
information  are  as  follows: 

•  Information  networks:  The  C4I  network  and  the  simulation  network  have  their  own  configuration 
parameters.  Most  of  the  time,  those  parameters  must  be  modified  to  allow  communication  between 
C4I  and  simulation  systems:  changes  in  IP  addresses  and  masks,  declaration  of  addresses  (hosts  file), 
declaration  of  the  default  gateway  and  routers.  The  technical  configuration  of  C4I  is  made  once  for  all 
when  the  system  is  delivered  to  the  forces  according  to  technical  military  guidance.  Changing  C4I 
parameters  thus  implies  the  reversibility  and  the  flexibility  of  the  system. 

•  Space-time  References:  C4I  systems  have  their  own  time  management  and  location  means,  based 
more  commonly  on  GPS  (Global  Positioning  System)  and  they  work  in  real  time  (BRAVO, 
ZOULOU).  On  simulation  side,  the  time  is  set  up  when  the  simulations  are  launched.  In  addition,  the 
time  could  evolve  differently  than  real  time.  In  the  case  of  a  training  exercise  for  instance,  the  exercise 
may  go  faster  for  pedagogic  objectives.  Then  the  C4I  time  is  usually  no  longer  suitable  with  the  needs 
of  the  exercise.  Now,  as  adequate  temporal  information  is  essential  for  the  time  stamping  of 
operational  messages,  the  C4I  time  has  to  be  managed  by  simulation  from  the  beginning  of  the 
education  course  or  training  exercise. 

The  identification  of  the  SIR-JANUS  static  interoperability  data  is  detailed  in  §3.3.1. 

2.1.2  Distribution  of  the  data 

The  technical  and  operational  data  having  been  identified  in  the  previous  section,  it  is  necessary  to  make 
them  available  to  both  systems,  C4I  and  simulation. 

The  data  must  be  distributed  to  both  systems,  in  accordance  with  the  needs  and  specificity  of  each  one: 

•  C4I  are  characterised  by  an  organisation,  hierarchical  levels  and  manning, 

•  Simulations  are  characterised  by  simulated  units  (more  or  less  aggregated)  and  associated  resources 
(fuel,  ammunition,  personals). 

C4I  and  simulation  systems  having  been  developed  in  very  different  manner,  the  semantic  correspondence 
between  them  is  not  immediate:  Hierarchy  (Battalion,  Company,  etc)  and  Organisation  (armoured, 
infantry,  etc)  are  not  consistent  a  priori.  As  an  example,  the  Company  can  be  called  Battery  or  Squadron, 
according  to  the  organisation  concerned. 

Under  these  conditions,  manual  transfer  of  information  from  one  system  to  another  is  the  obvious  solution. 
However,  it  needs  man  power,  it  is  time-consuming,  and  errors  may  occur  due  to  wrong  interpretation.  In 
addition,  for  each  modification  in  one  system,  it  is  necessary  to  check  and  make  the  corresponding 
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modifications  into  the  other  systems. 

To  solve  the  previous  issues,  it  is  then  easier  to  create  mechanisms  which  will  facilitate  the  common 
configuration  of  C4I  and  simulation  systems  for  education  and  training  purposes.  Such  a  mechanism 
includes: 

•  the  definition  of  one  or  several  data  interchange  formats  (DIF).  This  is  already  the  case  for  terrain  with 
SEDRIS.  But  SEDRIS  is  not  used  by  the  C4I  community  which  prefers  VMAP  and  DTED  files 
format.  Besides,  SISO  papers  mentioned  attempts  for  the  definition  of  a  DIF  ORBAT,  without  any 
standards  so  far.  However,  interchange  format  are  still  missing  for  the  transfer  of  tactical  information 
as  for  instance  operational  overlays,  initial  forces  situation  and  resources.  The  use  of  a  standard 
language  for  the  data  exchange,  as  XML  (Extented  Mark  up  Langage)  which  is  very  flexible  and 
easily  readable  with  many  freeware  tools  is  a  solution  to  recommend. 

•  the  definition  of  rules  (who  provides  what  ?).  C4I  systems  could  be  the  provider  for  operational  data. 

•  and,  finally  the  organisation  of  exchanges  when  the  overall  information  needed  is  completed.  The 
creation  of  a  conductor  to  collect,  map,  achieve  the  consistency  of  information  before  distribution  is  a 
solution  to  explore. 

The  mechanisms  developed  for  distribution  of  data  between  SIR  and  JANUS  through  ESTHER  are 
detailed  in  §3.3.2. 

2.2  Dynamic  interoperability 

This  second  stage  addresses  the  running  of  an  education  or  training  federation.  It  takes  into  account  the  bi¬ 
directional  connection  between  C4I  and  simulation  systems  according  to  operational  and  technical  point  of 
view. 

2.2.1  Operational  issues 

The  aim  is  to  allow  the  CP  officers  to  use  their  C4I  system  in  the  most  realistic  and  efficient  manner.  It 
means  that  the  concept  of  stimulation  explained  in  section  1.4  must  be  fully  implemented  as  describes 
below: 

•  Sending  Orders  to  the  subordinates  (i.e.  to  the  simulated  units).  Two  possibilities  have  to  be 
considered.  The  first  and  easiest  way  is  for  the  subordinate  units  to  own  a  C4I  same  as  or  interoperable 
with  the  training  audience's  C4I.  The  second  approach  is  at  the  simulation  level  to  be  able  to  extract 
from  the  OPO  the  most  important  elements  to  drive  automatically  simulation  models.  It  means  for  the 
latter  that  the  simulation  can  capture  the  operational  message  and  knows  how  to  decode  the 
information.  To  deliver  the  message  to  the  simulation  side,  the  trainee  must  send  it  to  a  virtual  C4I 
system  (i.e.  the  simulation)  referenced  in  the  Mail  user  directory. 

•  Sending  Requests  for  information  to  the  subordinates.  The  approach  is  the  same  than  above. 
However,  the  message  processing  could  be  more  or  less  automated.  As  an  example,  if  the  request  is  to 
obtain  the  logistic  status  of  the  subordinate  units,  the  answer  could  be  sent  automatically  from  the 
simulation.  Again,  it  is  mandatory  to  share  the  same  Mail  user  directory. 

•  Receiving  subordinates  reports:  it  deals  with  the  location  of  the  subordinates  units,  their  status  and 
the  status  of  the  obstacles  etc.  Those  messages  may  be  sent  automatically  from  simulation  at  fixed 
time  as  in  real  live.  They  may  also  be  generated  by  the  simulation  operator  when  it  is  needed  by  the 
hierarchy. 

Finally,  the  operational  issue  addresses  the  control  and  the  synchronisation  of  both  C4I  and  simulation 
systems.  It  mainly  deals  with  the  time  as  discussed  in  section  2.1.1.  Thus,  C4I  must  be  managed  by  the 
federation  as  "time  constraint"  federate.  Of  course,  C4I  will  never  be  time  regulating.  This  last 
requirement  is  useful  when  exercise  is  frozen  or  must  be  restarted  at  a  certain  time. 
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2.2.2  Technical  issues 

From  the  technical  point  of  view,  the  bi-directional  interoperability  must  be  considered  as  detailed  below: 

•  The  Simulation-to-C4I  connection:  the  generation  of  messages  toward  the  C4I  is  quite  simple  to 
perform  for  most  of  them.  The  process  consists  in  capturing  from  the  FILA  flow  the  data  necessary  for 
C4I,  assembling  them  according  to  the  appropriate  message  format,  and  sending  this  message  to  the 
C4I  according  to  the  shared  Mail  user  directory.  Flowever,  the  synthesis  or  the  aggregation  of  the 
information  to  the  higher  level  of  command  can  be  a  more  demanding  task.  Thus,  algorithms  must  be 
the  same  in  C4I  and  simulation  systems  to  keep  the  operational  consistency. 

•  The  C4I-to-Simulation  connection:  the  issue  is  really  more  complex.  The  operational  message 
information  must  be  extracted  (order  or  request)  and  made  understandable  for  simulation.  For  the 
OPO  (which  contents  a  lot  of  free  text),  the  orders  assignment  to  the  simulated  units  constitute  a  major 
stumbling  block.  It  requires  operational  expertise  in  order  for  the  simulated  units  to  execute  the  right 
mission. 

For  both  type  of  connections,  the  interoperability  implies  a  common  understanding  of  the  digital  battle 
space  in  order  to  handle  the  information  consistently,  and  the  use  of  the  same  interchange  standard  to 
transfer  the  information  between  both  systems.  The  C4I  Data  Model  and  the  Simulation/Federation  Object 
Model  must  converge,  or  at  least  partially  overlap,  otherwise  no  interoperability  could  be  forecast.  In  fact, 
it  means  that  the  way  to  describe  an  operational  object  in  both  systems  must  be  the  same  or  must  be  close 
enough  to  be  able  to  identify  common  attributes  with  same  meaning.  For  interchange  standard,  it  is 
recommended  for  the  simulation  to  use  the  same  mailing  system  than  the  C4I. 

Currently,  gateways  are  used  to  translate  and  map  the  information  between  C4I  and  simulation  systems. 
Their  use  presents  the  following  drawbacks: 

•  The  semantic  translation  happens  only  for  very  structured  simple  messages.  For  more  complex 
messages  such  as  OPO,  it  would  be  mandatory  to  use  special  keywords  in  free  text  fields  that  could  be 
recognised  by  the  gateway. 

•  These  gateways  are  designed  to  run  with  a  list  of  systems.  Whatever  the  interface  improvements  of 
one  of  these  systems,  the  gateway  must  be  adapted. 

That  is  why,  beyond  the  alignment  of  data  models,  it  also  appears  mandatory  in  the  future  to  align  the 
architecture  of  C4I  and  simulation  systems.  In  the  meantime,  the  gateway  approach  seems  an  interesting 
palliative  solution,  on  the  one  hand  to  ease  C4I  and  simulation  interoperability  while  no  standards, 
common  architecture  and  data  models  are  defined,  and  on  the  other  hand  to  help  improving  the  C4I- 
Simulation  interoperability  requirements. 

3.0  ESTHER 

The  main  recommendations  highlighted  in  section  2  come  from  the  ESTHER  R&T  program.  The 
proposed  solutions  to  bridge  the  gap  between  C4I  and  Simulation  systems  were  developed  ant  tested 
within  ESTHER.  The  lessons  learnt  are  detailed  below,  after  a  brief  presentation  of  the  main  features  of 
ESTHER. 

3.1  ESTHER  Overview 

ESTHER  "Environnent  Synthetique  de  Theatre  pour  l'entrainement  des  PC  de  Regiment"  is  a  Research 
and  Technology  Program  launched  by  the  DGA  (Delegation  Generate  pour  l’Armement)  in  2001. 

ESTHER  is  a  framework  allowing  the  connection  of  live,  virtual  and  constructive  simulations  and  C4I 
systems.  ESTHER  provides  services  to  configure,  manage  in  real  time  and  prepare  after  action  review  for 
education  courses  and  training  exercises.  Data  consistency,  C4I-Simulation  interoperability  and  RTI 
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optimization  for  distributed  connection  are  also  studied  and  demonstrated  within  ESTHER. 

The  objectives  of  ESTHER  are  of  two  types: 

•  Operational  objectives  divided  into: 

>  Distributed  training  on  several  sites, 

>  Reduction  of  the  man  power  and  the  time  required  to  conduct  and  configure  education  courses  and 
training  exercise, 

>  Increase  of  the  operational  realism, 

>  Remote  pedagogy  and  distributed  debriefing, 

>  Training  at  home  station. 

•  Technical  objectives  divided  into: 

>  Use  of  the  French  C4I  system,  SIR, 

>  Development  of  HLA  interfaces  for  JANUS  and  GESI  simulations, 

>  Simulation  of  operational  data  networks, 

>  Automation  of  the  C4I-simulation  connection  via  SICAT  and  HLA, 

>  Experimentation  of  a  Federation  (ESTHER  FOM)  where  JANUS,  GESI  and  SIR  must  run  all 
together. 

The  ESTHER  program  is  divided  into  three  stages  over  4  years.  The  two  years  first  stage,  ESTHER 
GIVI,  is  now  completed  with  experimentations  performed  early  2003.  The  second  stage,  ESTHER  G1V2 
will  be  finalised  in  2004.  The  last  stage  ESTHER  G2  will  address  the  full  program  objectives  and  will  be 
tested  during  a  real  Battalion  exercise  in  2005. 

3.2  ESTHER  GIVI  Main  Studies 

ESTHER  GIVI  studies  addressed  the  following  topics: 

•  The  development  of  an  HLA  plug-in  framework, 

•  The  implementation  of  an  HLA  interface  for  JANUS,  based  on  RAL. 

Note  :  RAL  (RTI  Abstraction  Layer)  is  a  tool  suite  developed  by  the  ANPROS  (French  Navy 
Operational  Research  and  Simulation  Centre)  including  a  FOM  independent  library  used  as  a 
middleware  between  the  RTI  and  the  simulation  code. 

•  The  development  of  models  for  tactical  data  network, 

•  The  realisation  of  an  interoperability  gateway  between  SIR  and  JANUS. 

The  scope  of  this  document  is  limited  to  the  explanation  of  this  last  item. 

3.3  ESTHER  GIVI  C4I-Simulation  interop. 

The  ESTHER  GIVI  interoperability  studies  between  SIR  and  JANUS  are  detailed  in  the  sections  below 
according  to  the  two-stage  approach,  static  interoperability  and  dynamic  interoperability. 

3.3.1  Static  interoperability  data 

The  operational  elements  to  configure  both  SIR  and  JANUS  are  generated  from  an  ESTHER  as  a  unique 
source.  The  information  for  systems  configuration  managed  within  ESTHER  are  detailed  below. 

The  Terrain:  a  terrain  editor  was  developed  by  the  CROSAT  (Army  Operational  Simulation  &  Research 
Centre)  to  generate  JANUS  terrain  data  base,  from  DTED  and  VMAP  files.  Thus,  it  is  possible  to  generate 
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any  terrain  needed  for  JANUS. 

On  the  ESTHER  side,  the  terrain  is  a  RASTER  map  easily  generated  from  USRP  data,  except  for  junction 
problems  which  require  an  extra  cartographic  tool  suites. 

On  the  SIR  side,  the  RASTER  map  (re-used  by  ESTHER)  is  supplemented  by  DTED  data. 

Under  these  conditions,  the  terrain  data  base  must  be  locally  defined  within  each  system.  However,  the 
name  of  the  terrain  is  transmitted  from  ESTHER  to  JANUS  in  the  "Terrain"  section  of  an  export  file  (see  § 
0  ).  With  this  name,  JANUS  server  and  its  clients  are  able  to  download  the  suitable  terrain  from  JANUS 
data  base.  Currently,  the  terrain  areas  available  in  ESTHER  are  Mailly-le-Camp  and  the  surroundings  of 
Montpellier. 

The  Order  of  battle:  A  dedicated  ESTHER  editor  is  used  to  create  the  ORBAT  which  comply  with  the 
requirements  of  SIR  and  JANUS.  Each  node  of  the  hierarchical  structure  is  either  a  Force  or  a  Unit.  For 
Forces,  attributes  can  be  defined,  such  as  name,  colour,  type  (FRIENDLY,  OPPOSITE,  NEUTRAL).  For 
each  Unit,  there  is: 

•  a  specific  SIR  section  including:  the  level  (Company,  Platoon,  etc),  the  type  (PC  or  Unit),  the 
organisation  (Infantry,  Cavalry,  etc),  the  speciality  (Anti-tank,  etc),  manning  (Officers,  NCO, 
Soldiers). 

•  a  specific  JANUS  section  where  the  following  information  must  be  specified:  the  type  of  platform,  the 
logo,  the  percentage  of  initial  ammunition  and  fuel  allocation,  etc. 

An  ORBAT  library  is  available,  which  includes  in  particular,  for  the  Friendly  side,  a  French  BattleGroup 
(GTIA)  essentially  made  of  armoured  or  infantry  forces  and  for  the  Opposite  Force,  different  formations 
corresponding  to  a  standard  enemy. 

This  ORBAT  is  transmitted  to  JANUS  in  the  "ORBAT"  section  of  an  export  file  (see  §3.3.2).  This 
ESTHER  exchange  format  is  specific,  as  it  was  designed  jointly  with  CAE  to  ensure  compatibility  with 
GESI. 

Tactical  information:  A  dedicated  ESTHER  editor  is  used  to  define  operational  overlays  with  main 
information  including  Assembly  Areas  (AA),  co-ordination  lines,  reports  lines.  Exporting  this  information 
with  the  ORBAT  is  planned  in  the  next  ESTHER  version. 

Initial  situation:  A  dedicated  ESTHER  editor  is  used  to  set  the  initial  location  of  the  simulated  entities  of 
the  ORBAT  (friendly  and  opposite  forces)  on  the  terrain;  these  positions  will  be  exported  to  JANUS  (see 
§3.3.2).  JANUS  initial  planning  (initial  displacements)  will  be  defined  in  the  next  ESTHER  version. 

Initial  resources:  The  following  information  can  be  configured  from  ESTHER: 

•  The  composition  of  the  crews  belongs  to  the  ORBAT.  This  information  is  not  processed  by  JANUS 
which  only  handles  entities,  but  it  is  exported  to  SIR. 

•  The  fuel  and  ammunition  resources  are  defined  in  the  ORBAT,  expressed  as  a  percentage  of  the  initial 
allocation.  This  information  is  used  by  JANUS  when  the  platform  is  generated.  The  default  value  is 
100%. 

Tactical  communication  networks:  A  dedicated  ESTHER  editor  is  used  to  create  the  different  data 
communication  networks,  as  the  type  of  protocol  to  use.  Each  SIR  officer  defined  in  the  ORBAT  is  seen 
as  a  network  node. 

The  technical  elements  to  configure  both  SIR  and  JANUS  are  generated  from  an  ESTHER  unique  source 
as  for  the  operational  information.  They  are  detailed  hereafter: 

Information  networks:  A  dedicated  ESTHER  editor  (the  hardware  configuration  editor)  is  used  to  define 
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information  relating  to  ESTHER  federation,  which  includes: 

•  Sites  where  hardware  is  deployed, 

•  Each  hardware  item  characterised  by  a  name,  an  IP  address,  a  type,  and  a  mask. 

Depending  on  the  type,  additional  information  is  entered: 

•  For  SIR:  SICAT  address, 

•  For  a  JANUS  client:  its  server, 

•  The  network- type  hardware  (routers  for  multisite,  Switch  for  single  site). 

The  configuration  for  each  hardware  component  is  established  in  advance.  This  configuration  task  is 
inevitably  manual. 

Mailing  system:  The  subordinates  of  the  SIR  Battalion  CP  are  SIR  Companies.  Each  SIR  must  thus 
belong  to  the  ORBAT  and  be  linked  to  a  platform.  It  must  have  an  electronic  SICAT  mail  address,  and  be 
declared  in  the  SIR  mail  user  directory.  Each  SIR  being  declared,  it  may  send  and  receive  messages  in 
SICAT  format  (see  §  3.3.3). 

Space-time  References:  SIR  is  provided  with  a  time  and  location  reference  based  on  the  GPS.  In  the  case 
of  an  education  courses  or  a  training  exercise  where  the  terrain  and  the  time  could  be  different  than  the 
real  situation,  the  GPS  is  deactivated  and  the  computer  clock  is  configured  with  the  exercise  time  in 
accordance  with  the  federation  time. 

3.3.2  Static  data  distribution 

When  all  the  previous  information  are  fully  defined  in  ESTHER,  they  must  be  sent  to  the  SIR  and  JANUS. 

According  to  the  approach  described  in  §2.1.2,  the  distribution  of  data  is  handled  via  a  third  system.  This 
is  ESTHER  which  uses  data  interchange  format  and  an  exchange  language,  XML. 


ESTHER 


Preparation 
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Static  Distribution  in  ESTHER 


The  interchange  format:  As  the  format  used  by  the  SIR  to  export  or  import  ORBAT  is  not  a  DIF  format, 
the  only  concern  is  the  export  of  ESTHER  information  towards  JANUS  and  GESI.  The  ESTHER  ORBAT 
being  very  precise  for  SIR  requirements,  the  overall  information  is  not  required  by  simulations.  As  an 
example,  the  topics  as  Armoured,  Infantry,  Artillery,  Engineering  and  Units  sub-categories  are  not 
relevant  for  simulation.  On  the  other  hand,  simulations  need  to  know  the  exact  platform  name.  Both 
JANUS  and  GESI  servers  dispatch  the  ORBAT  entities  between  their  clients.  As  these  simulation  systems 
own  their  file  format  to  store  the  data,  ESTHER  can  not  comply  with  these  two  DIF  and  therefore  will 
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generate  an  XML  file;  each  simulation  being  in  charge  of  completing  the  translation. 

The  exchange  language:  The  XML  language  is  used  to  export  the  following  information: 

•  SIR  XML  files:  Two  XML  files  are  generated  to  describe  the  Friendly  ORBAT,  and  Opposite 
ORBAT.  They  comply  with  the  SIR  import/export  XML  format; 

•  JANUS  XML  file:  A  third  XML  file  is  the  JANUS  and  GESI  export  file  which  contains  various 
sections  describing: 

>  ORBAT  with  the  initial  location  for  each  platform, 

>  the  relations  between  forces  (friendly  and  opposite), 

>  the  description  for  each  simulation  server  of  the  names  of  its  clients, 

>  the  dispatching  of  ORBAT  units  between  simulation  workstations, 

>  the  weather  conditions, 

>  the  name  of  the  terrain, 

>  the  time  of  the  federation  when  starting  the  exercise, 

>  the  name  of  the  federation  and  other  HLA  information. 

•  Distribution  of  the  XML  files:  they  are  transmitted  via  FTP  from  ESTHER  to  simulations  and  SIR. 
For  a  multisite  federation  (planed  for  G2),  the  use  of  an  ESTHER  relay  is  foreseen. 

•  Processing  of  the  XML  files:  The  SIR  XML  file  is  processed  according  to  the  SIR  ORBAT  loading 
procedure.  For  JANUS,  a  manual  processing  procedure  is  started  on  each  JANUS  server  for  data 
import  and  insertion  into  the  data  base.  This  procedure  is  mandatory  to  convert  the  ESTHER  ORBAT 
into  the  simulation  files  format  (JANUS,  but  also  GESI  in  next  version). 

Once  this  procedure  executed,  the  education  courses  or  the  training  exercise  can  be  launched  by  ESTHER. 
Both  ESTHER  and  JANUS  are  HLA  federates  in  "regulating"  and  "constraint"  mode.  The  "RAL  Player 
Recorder"  ESTHER  federate  (data  logger)  is  in  "constraint"  mode  only  for  the  replay. 


3.3.3  Dynamic  Interoperability 


Considering  that  the  SIR  is  an  operational  system  that  can  not  be  modified  without  restricted  conditions 
and  considering  the  workload  already  spent  to  develop  a  JANUS  HLA  interface  without  changing  the 
overall  architecture,  it  has  been  decided  to  take  into  account  the  dynamic  interoperability  between  SIR  and 
JANUS  via  a  SIR- Simulation  gateway  integrated  in  ESTHER. 


The  picture  below  depicts  the  principles  of  JANUS-SIR  coupling  via  ESTHER. 
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The  capabilities  of  this  gateway  are  presented  below. 

Gateway:  It  is  a  component  of  the  ESTHER  basic  software  and  is  based  on  a  SIR  piece  of  software  This 
component  is  part  of  each  ESTHER  client.  It  makes  it  possible  to  create  SIR  messages  from  the 
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information  captured  from  the  HLA  simulation  flow.  In  addition,  this  gateway  stores  every  SICAT 
messages  exchanged  during  the  running  of  the  federation. 

Exchange  format:  The  HLA  objects  and  interactions  are  converted  into  SICAT  messages  for  SIR. 

Generation  of  messages:  The  process  used  to  generate  SICAT  messages  is  depicted  on  the  diagram 
below.  It  consists  in  extracting  from  the  HLA  flow  the  overall  information,  and  encapsulating  it  into  an 
appropriate  SIR  message  selected  by  an  ESTHER  operator.  The  address  for  the  final  recipient  is  selected 
from  the  shared  Mail  User  Directory.  The  message  generated  is  finally  sent  via  the  SIR  network  according 
to  the  SMTP  protocol. 


SICAT  message  generation  in  ESTHER 

SIR  Operational  messages:  The  messages  being  generated  from  ESTHER  are  listed  below: 

•  Report  messages  from  Company  to  Battalion: 

>  SITREP/at  a  time:  Periodic  Friend  and  Opposite  Situation  Report  at  a  time, 

>  SITREP/PTSITU:  Specific  Friend  and  Opposite  Situation  Report, 

>  CRRENS:  Opposite  Situation  Report  which  belongs  to  the  intelligence  chain, 

>  SITEFF :  Situation  Report  on  human  resources, 

>  SYNSAN:  Medical  Situation  Report. 

•  Messages  from  Battalion  to  Company: 

>  INFOSITREF,  Friendly:  Reference  picture  for  Friendly  Forces, 

>  INFOSITREF,  ENI:  Reference  picture  for  Opposite  Forces, 

>  INFOSITREF,  Environ.:  Reference  picture  for  environment, 

>  INFORENS:  Reference  picture  for  the  intelligence  chain. 

•  Messages  on  obstacles  (bi-directional): 

>  SITOBST  REF.:  Reference  Situation  for  obstacles, 

>  SITOBST  MODIF.:  Change  of  Status  for  obstacles. 

•  General  messages: 

>  ALARM  and  END/ALARM 

>  GENTEXT:  Free  text  message. 

Message  processing  by  SIR:  The  messages  sent  from  ESTHER  are  processed  by  the  SIR  in  the  same  way 
as  native  SIR  messages.  According  to  the  SIR  configuration  and  the  types  of  messages,  the  different 
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messages  are  processed  automatically  or  not,  and  integrated  automatically  or  not  into  the  Consolidated 
Tactical  Picture. 

Operational  co-ordination:  ESTHER  is  designed  to  be  the  “master”  of  the  federation.  Thus,  this 
principle  is  applied  as  follows: 

•  ESTHER  starts  and  freezes  the  federation  according  to  the  following  process:  as  every  federates  are 
time  "regulating",  freezing  the  federation  means  for  ESTHER  to  never  accept  time  advance  grant. 

•  Considering  the  disconnection  of  the  SIR  GPS  as  described  above,  the  SIR  operates  according  to  its 
own  system  clock  which  is  not  controlled  by  the  federation. 

With  this  version  of  ESTHER,  the  choice  of  the  federation  time  is  thus  imposed  by  the  SIR  system  time, 
which  confers  a  certain  rigidity  to  the  whole  system,  preventing  the  capacity  of  freezing  and  restarting  the 
exercise  as  wanted.  For  the  next  version,  an  operating  system  time  management  service  will  be  integrated 
between  the  SIR  and  the  federation. 

3.4  Conclusion 

The  gateway  between  SIR  and  JANUS  developed  under  the  umbrella  of  ESTHER  was  used  during  the 
ESTHER  GIVI  experiments  which  took  place  during  the  first  quarter  2003  in  the  JANUS  centers  of  the 
Army  Infantry  School  (EAI)  of  Montpellier  and  of  the  Armoured  School  (EAABC)  of  Saumur. 

The  SIR  Stimulation  obtained  via  ESTHER  was  considered  to  be  very  interesting  by  the  two  schools  for 
different  applications.  The  EAI  wished  to  use  ESTHER  for  its  DEFense  TEMPoraire  (DEFTEMP)  annual 
exercise.  The  ESTHER  experimentation  to  DEFTEMP  is  detailed  hereafter. 

4.0  INFANTRY  DEFTEMP  EXERCISE 
4.1  Exercise  principles 

The  "Defense  Temporaire"  (DEFTEMP)  training  exercise  is  held  every  year  at  the  Infantry  School  in 
Montpellier.  Following  the  ESTHER  GIVI  experiment  campaigns,  the  purpose  to  deploy  ESTHER  for 
the  DEFTEMP  exercise  is  to  use  the  SIR  /  ESTHER  /  JANUS  combination  to  generate  an  operational 
environment  to  train  captains  to  command  from  their  SIR  embedded  inside  the  VAB  (Forward  Armoured 
Vehicle). 

Thus,  the  objectives  are  to: 

•  Simulate  the  Terminal  Information  System  (SIT),  using  SIR  messages  generated  automatically  from 
ESTHER, 

•  Reproduce  a  realistic  SIR  environment  for  the  captain, 

•  Assess  ESTHER  limits  with  a  complex  JANUS  exercise. 

The  main  features  of  the  exercise  are  as  follows: 

•  The  trainee  group  is  made  of  9  captains,  with  two  captains  per  VAB  and  one  captain  on  a  SIR  in  a 
control  room. 

•  The  scenario  is  intended  to  oppose  a  defending  Friendly  force  consisting  of  a  mechanized  Battalion, 
with  its  four  Companies  leaded  by  the  trainees,  to  an  attacking  Opposite  force  made  of  two 
mechanized  Battalions  and  one  armoured  tank  Squadron. 

•  The  whole  forces  amount  to  about  1,600  entities  and  the  intended  scenario  duration  is  estimated  to  5 
hours. 
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4.2  Assets 

The  assets  were  deployed  for  both  Forces  according  to  the  following  diagram: 
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Exercise  Organisation 


•  SIR:  one  SIR  WS  for  the  High  controller  at  Battalion  Level,  and  one  SIR  WS  for  each  one  of  the  4 
Company  leaders  in  VAB 

•  JANUS:  1  JANUS  server  for  Friendly  and  Opposite  forces  and  1  JANUS  client  for  each  Company, 

•  ESTHER:  The  server,  1  WS  for  EXCON,  1  WS  for  SIR  Stimulation,  1  WS  for  real  time  Analysis  et 
After  Action  Review, 

•  The  SIR  network  between  each  SIR  WS, 

•  The  Simulation  network  between  JANUS  WS  and  ESTHER  WS, 

•  The  SIR  Stimulation  Network  between  ESTHER  SIT  emulation  WS  and  the  SIR  WS, 

•  The  Voice  networks  between  SIR  CPs  and  between  JANUS  operators  and  SIR  CP. 

Operational  PR4G  communication  devices  were  deployed  for  its  exercise  to  add  realism. 


4.3  Execution 


The  exercise  was  executed  according  to  the  planned  objectives  and  program: 

•  A  week  was  devoted  to  the  technical  building  of  the  exercise;  i.e.  the  configurations  were  set  up  for 
ESTHER  (terrain  and  the  exercise  ORBAT),  SIR,  and  JANUS.  The  week  ended  with  a  rehearsal  of 
the  exercise. 

•  During  a  second  week,  the  exercise  was  executed  and  repeated  several  times,  with  the  trainee  captains 
changing  roles:  as  Unit  Leaders  or  Leader  Deputies. 

•  At  the  end  of  the  exercise  period,  a  demonstration  was  presented  to  Infantry  School  (EAI) 
commanding  general. 

From  a  technical  point  of  view,  the  organisation  retained  for  ESTHER  complied  with  the  Infantry  School 

requirements:  the  messages  sent  to  the  captains  were  generated  by  a  single  environment  controller  from 

the  DISTAFF.  The  messages  were  handled  as  follows: 

•  Report  Request  by  the  captain  to  the  section/platoon  leader  through  the  tactical  voice  communication 
system, 

•  Message  generation  request  by  the  JANUS  operator  to  the  DISTAFF  through  the  controller’s  voice 


RTO-MP-MSG-022 


5  - 15 


HLA  Synthetic  Environment  Framework  for  CPX 


ORGANIZATION 


communication  network. 

The  combination  of  three  ESTHER,  JANUS  and  SIR  components  for  DEFTEMP  exercise  was  a  success. 
The  lessons  are  detailed  below. 

4.4  Lessons  learnt 

Observing  the  captains’  activities  during  the  exercise  made  it  clearly  appear  that  voice  communication  and 
the  map  were  preponderantly  used  by  the  Unit  Leader.  Most  of  the  time,  SIR  was  only  used  by  deputy 
officers. 

As  the  main  explanation,  the  captains  put  forward  that  leading  the  engagement  is  a  very  heavy  workload. 
They  have  a  feeling  that  SIR  represents  an  extra  workload,  since  the  information  is  not  automated  at  the 
lower  level.  Entering  information  manually  on  SIR  is  considered  as  taking  longer  than  on  a  paper  map. 
Besides,  the  representation  differences  between  the  paper  map  and  the  electronic  map  have  a  penalizing 
effect. 

This  on-the-spot  feeling  expressed  by  the  trainee  captains  was  analysed  by  the  School  officers  who  made 
the  following  comments  and  correction  : 

•  The  SIT  system  will  be  deployed  in  5  years  time.  The  captain  and  their  SIR  will  thus  be  the  entry 
point  of  the  digital  battle  space  during  this  period. 

•  Using  the  paper  map  can  be  judged  more  effective  at  present,  but: 

>  the  paper  map  can  only  be  used  by  the  captain,  and  is  of  no  help  for  the  higher  echelon, 

>  the  C4I  value  added  functions,  for  the  terrain  especially,  are  much  effective  than  those  provided 
by  the  paper  map, 

>  taking  SIR  in  hand  (training)  will  accelerate  the  process. 

•  So,  it  is  necessary  to  make  an  effort  to  become  quite  familiar  with  SIR,  and  to  acquire  automatic 
gestures  which  will  allow  more  time  for  tactical  reflection. 

In  addition,  the  SIR  and  voice  communication  combination  must  be  mastered.  It  clearly  appears  that  using 
SIR  must  be  considered  as  a  three-phase  process: 

•  Initial  deployment  of  forces,  where  SIR  is  preponderant.  It  should  be  noted  that  the  Battalion  OPO 
must  be  "physically"  presented  by  the  Colonel  to  his  Captains,  with  whom  contact  is  essential  so  that 
the  major  effect  intended  can  be  correctly  transmitted. 

•  Leading  the  engagement,  where  voice  communication  is  preponderant,  and  where  the  automation 
allowed  by  SIR  should  provide  a  significant  support  to  the  Captain.  During  this  phase,  the  captain 
seeks  proximity  with  his  Squad  leaders  to  be  aware  in  real  time  of  any  situation  changes.  In  such 
conditions,  the  deputies  can  be  in  charge  of  the  SIR,  essentially  to  follow  Friendly  and  Opposite  forces 
locations,  with  a  reporting  to  the  Battalion. 

•  Reorganisation  at  the  end  of  the  engagement,  where  the  SIR  becomes  again  preponderant  for  a 
precise  reporting  to  the  Battalion,  and  transmission  of  logistic  data. 

This  information  relating  to  SIR  being  set  forth,  the  SIR- Simulation  connection  via  ESTHER  is  now 
analysed: 

•  As  expected,  stimulation  through  JANUS  makes  it  possible  to  give  the  Captains  a  much  more 
stimulating  (even  stressful)  environment  than  the  conventional  in-room  training  environment. 

•  Because  of  their  workloads,  the  Captains  have  not  regularly  made  requests  for  reports.  Moreover,  the 
time  necessary  for  consolidation  to  the  Battalion,  and  then  for  distribution  to  the  Companies  (Friendly 
and  ENI  InfoSitRef  messages)  have  resulted  in  sometimes  important  time-lags  with  respect  to  the 
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current  situation  provided  by  voice  communication. 

To  motivate  the  Captains  by  giving  them  a  regular  and  consistent  stimulation,  two  corrective  measures 
have  been  retained: 

•  SIR  Initial  situation:  it  must  be  defined  during  the  initial  phase,  i.e.  at  the  end  of  the  reconnaissance 
phase  performed  by  the  squads,  jointly  between  the  Captains  and  the  Squad  Leaders  in  the  captain’s 
VAB, 

•  SIR  situation  updating:  the  following  messages  have  to  be  sent  as  follows  : 

>  PTSITU  messages  must  be  regularly  transmitted  by  default  by  the  DISTAFF,  for  example  every 
30  minutes. 

>  The  Captain’s  PTSITU  messages  to  the  Battalion  must  be  transmitted  with  the  same  periodicity, 
with  a  1 0  minutes  time  shift. 

>  The  Battalion  InfoSitRef  message  will  follow  the  same  logic. 

>  The  other  messages,  especially  concerning  obstacles,  are  transmitted  as  appropriate. 

This  very  useful  operational  experience  on  the  Captains’  training,  derived  from  the  DEFTEMP  exercise, 
will  be  used  to  improve  the  capacities  of  the  next  ESTHER  version,  more  particularly  from  the  SIR- 
Simulation  coupling  point  of  view.  The  outlines  are  described  below. 

5.0  WHAT  IS  NEXT 

In  accordance  with  the  incremental  logic  of  the  project,  the  next  version,  ESTHER  G1V2,  will  evolve 
according  to  the  functions  identified  as  necessary  from  the  lessons  learnt  during  the  experiments  and  the 
DEFTEMP  exercise. 

5.1  New  capabilities 

Among  the  new  functionalities  (except  the  gateway),  the  following  topics  will  be  considered: 

•  Multisite:  Practical  application  of  study  results,  with  the  implementation  of  gateway  federates, 

•  New  federate:  GESI  simulation, 

•  Logistics:  attrition  of  crews, 

•  Simulation  of  communications:  on  the  basis  of  existing  model  in  range,  addition  of  the 
intervisibility  aspect  and  of  the  electromagnetic  propagation, 

•  MMI:  Taking  into  account  of  new  needs  (aggregation,  . . .). 

5.2  C4I-Simulation  Interoperability 

In  addition  to  the  above-mentioned  new  functionalities,  the  SIR- Simulation  interoperability  topic  will  be 
improved  on  two  axes: 

•  Improvement  of  connection, 

•  Introduction  of  SIR  to  JANUS  connection. 

5.2.1  JANUS  to  SIR  improvement 

As  the  existing  linkage  between  JANUS  and  SIR  was  a  success  during 
lessons  learnt  led  to  precise  specifications.  These  are,  more  particularly: 

•  Management  of  the  federation  time:  the  use  of  a  time  protocol  should 
overall  federation  time  control  by  the  DISTAFF, 
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•  Implementation  of  new  messages  with,  for  example,  new  SICAT  and/or  XL  messages,  or  the 
automatic  generation  of  certain  messages  (PTSITU  or  CRPOSXL). 

5.2.2  Introduction  of  Command  Agents 

Two  kinds  of  Command  Agents  will  de  developed  for  ESTHER  G1V2: 

•  Introduction  of  an  ACE  (ESTHER  Command  Agent)  to  simulate  neighbours  environment,  with  the 
purpose  of  decreasing  the  amount  of  personal  required  to  perform  this  task.  SIR  messages  will  drive 
the  JANUS  Units  representing  neighbours  environment, 

•  Introduction  of  an  ACE  for  an  automatic  generation  of  messages  after  a  request  for  information 
(Location,  Logistic),  with  the  purpose  of  simulating  the  SIT. 


6.0  CONCLUSION 


ESTHER  is  a  R&T  program  contributing  to  propose  C4I- Simulation  interoperability  solutions  for  current 
education  courses  and  training  exercises  with  special  interest  on  JANUS  and  SIR.  ESTHER  addresses  the 
interoperability  between  SIR  and  JANUS  according  to  a  two-stage  approached.  First  the  static 
interoperability  which  deals  with  the  configuration  of  the  two  systems  before  execution,  and  second  the 
dynamic  interoperability,  which  deals  with  the  bi-directional  connection  during  the  C4I  and  simulation 
systems  running  and  with  their  co-ordination,  during  run  time. 

Under  the  umbrella  of  ESTHER  GIVI,  the  connection  from  JANUS  towards  SIR  was  thoroughly 
addressed:  The  conditions  of  the  interoperability  were  met  with  the  identification  and  sharing  of  the 
needed  data  between  both  systems  (static  interoperability)  and  the  most  significant  SICAT  operational 
messages  were  built  from  the  HLA  simulation  flow  data  (dynamic  interoperability).  Following  successful 
experiments,  the  Army  asked  for  ESTHER  participation  in  the  Infantry  DEFTEMP  exercise,  whose 
operational  range  was  tenfold  increased  by  this  realistic  stimulation  of  the  trainees  via  their  SIR. 

This  very  rich  operational  experience  on  the  Captains’  training  will  be  used  to  improve  the  capabilities  of 
the  next  ESTHER  version,  more  particularly  from  the  SIR- Simulation  coupling  point  of  view.  For  the  next 
version,  ESTHER  G1V2,  the  JANUS  to  SIR  connection  will  evolve,  by  taking  into  account  new 
operational  messages.  Besides,  the  SIR  to  JANUS  connection  will  be  addressed  as  detailed  below: 

•  Taking  automatically  into  account  the  messages  of  requests  for  location/status  reports  from  the 
Company  to  the  Squads  (position,  manning,  resources,  . . .), 

•  Taking  automatically  into  account  of  the  neighbours  environment  by  a  Command  Agent. 

As  for  the  previous  version,  experiments  and  a  real  Army  exercise  will  provide  and  enrich  the  lessons 


learnt. 
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Abstract 

Modeling  and  Simulation  at  the  Slovak  Armed  Forces  has  been  since  earlier  90's  utilized  to 
improve  training,  develop  doctrine,  tactics  and  materials,  and  improve  combined  and  joint  coordination. 
Recently  the  question  of  linking  existing  and  future  C3I  systems  with  the  Simulation  Federation  has 
emerged  and  is  being  reflected.  The  ability  to  develop  a  versatile  modeling  and  simulation  system  in 
Slovakia  linked  with  Air  Force  C3I  ATC  system,  that  can  evolve  with  standards  and  tools  is  a  big 
challenge. 

An  approach  has  recently  been  identified  to  meet  this  challenge  through  modular,  open- 
architecture  Training  and  Simulation  Centers  (TSC).  The  TSC  provide  a  robust  combined  arms 
environment  where  tactics,  equipment,  and  training  development  can  be  addressed.  The  TSC  is  capable  of 
brigade,  air  wing  and  below  level  CAX  exercises,  and  include  pre-loaded  scenarios  with  real  world 
databases.  The  TSC  are  being  enhanced  through  the  addition  of  Virtual  Full  Mission  Simulators  training 
facilities,  Digital  Communications  emulators,  and  with  the  links  to  the  Air  Force  C3I  system  standard 
called  "LETVIS",  which  is  an  important  element  of  the  Slovak  C3I ASOC  system.  This  interoperable  vital 
concept  was  and  is  being  successfully  implemented  at  the  Air  Force  Academy  and  appropriate  C3I  posts 
in  Slovakia 

The  functional  link  and  consistent  communication  standard  between  TSC  and  C3I  system  provides 
Slovak  Armed  Forces  with  the  capability  to  train  commanders,  staff  personnel,  pilots,  tank  crew  and 
cadets  on  developing  tactics  and  standard  procedures.  Each  configuration  of  CAX  using  C3I  link 
feedback  information  has  simulation  tools,  equipment,  and  capability  for  planning  and  executing 
operations  interoperable  with  other  DIS/HLA  simulation  and  C3I  nodes  and  operational  facilities.  This 
concept  provides  an  expandable  and  flexible  simulation,  command  and  control  environment  suitable  for 
training  and  the  development  of  tactics  and  equipment,  which  significantly  supports  the  process  of 
Slovakia  integration  to  NATO. 


Current  Capabilities 

The  Armed  forces  of  the  Slovak  Republic  (OSSR)  currently  have  Modeling  and  Simulation 
capabilities  and  C3I  Air  Force  ATC  Systems  capabilities  at  different  locations.  All  these  locations  are 
very  fast  becoming  very  modem  CAX  platform  training  and  exercise  centers  in  the  Central  Europe. 
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The  Air  Force  Academy  located  at  Kosice  (location  of  Training  and  Simulation  Center  (TSC)) 
provides  a  high  -  level  general  science  and  military  academic  program  to  all  branches  of  the  OSSR.  As 
part  of  the  instruction  here,  there  are  virtual  simulators  of  Slovak  Air  Force  operated  light  combat  aircrafts 
used  for  individual  pilot  training,  dog  fighting  training  and  flight  training 

The  Military  Academy  at  Liptovsky  Mikulas  (location  of  Training  and  Simulation  Center  (TSC)) 
provides  a  high  -  level  general  science  and  military  academic  program  to  all  branches  of  the  OSSR.  As 
part  of  the  instruction  here,  there  are  virtual  simulators  used  for  heavy  vehicle  driver  training,  and  Anti- 
Aircraft  (  AA)  gun  training. 

Another  simulation  is  in  a  classroom  where  a  large  3-D  table  -  top  terrain  simulation  board  with 
approximately  1/48  -  scale  model  tanks  is  used  for  maneuver  training.  Students  radio  C2  directions  for 
these  tanks,  using  R  -123  and  R  -  173  radios,  to  an  operator  who  moves  the  model  tanks  as  directed. 

Linked  with  above  described  training  systems  into  the  Simulation  Federation  is  the  C3I  Air  Force 
ATC  system  is  called  LETVIS.  This  system  is  a  PC-based  system  consisting  of  several  software 
applications  that  are  used  to  monitor  and  evaluate  the  Slovak  airspace  situation.  It  provides  air  situation 
data  display,  radar  data  processing,  and  flight  data  processing.  It  exchanges  information  via  a  LAN  and  a 
special-purpose  leased  WAN. 

Additional  C3I  Air  Force  system,  going  to  be  linked  is  Air  Sovereignty  Operations  Center 
(ASOC).  The  ASOC  provides  the  capability  to  support  airspace  monitoring  and  command  and  control 
over  mission  execution  ofair  operations.  It  is  a  Sun  Solaris-based  system.  Its  initial  capability  allows  the 
development  and  exchange  of  a  national  Recognized  Air  Picture  (RAP).  It  currendy  receives  air  situation 
and  flight  plan  data  from  LETVIS  system  or  in  simulation  mode  generated  data.  It  is  intended  to  be  used 
to  conununicate  with  other  ASOCs  in  the  region,  in  accordance  with  bilateral/multilateral  agreements. 

The  Slovak  MoD  supported  in  the  year  2000  a  Letter  of  Request  (LOR)  to  US  Army  Simulation 
Training  and  Instrumentation  Command  (  PEO  STRI  )  for  the  Modular  Semi  -  Automatic  Forces  ( 
ModSAF  )  Brigade  and  Battalion  level  simulation.  This  training  and  exercise  simulation  creates  and 
controls  virtual  battlespace  entities  that  move,  shoot,  communicate,  and  react  without  excessive  operator 
intervention. 

ModSAF  (now  update  OneSAF)  is  be  hosted  and  operated  on  Linux  machines  by  the  Air  Force 
Academy  and  Military  Academy  in  Kosice  and  Liptovsky  Mikulas.  A  training  audience  at  the  collocated 
Training  and  Simulation  Centers,  which  trains  and  teaches  military  tactics  and  doctrine,  and  use  the 
simulation  for  training  at  the  Battalion  and  Brigade  Commander  and  staff  officer  level  and  for  use  in 
training  cadets  at  the  Squadron  and  Wing  operations  level. 


C3I  Systems  and  CAX  Platform 

NATO  nations  are  required  to  support  a  wide  range  of  cooperative  functions  including  combined 
training.  Because  it  provides  a  cost-effective  supplement  to  conventional  training,  CAX  is  gaining  strong 
acceptance  in  NATO.  While  of  growing  importance,  this  requirement  is  in  some  background  information 
is  presented. 

In  1992,  SHAPE  established  an  operational  requirement  for  a  NATO  CAX  capability.  NATO 
clearly  recognized  the  value  of  CAX  in  an  environment  of  constrained  funding,  reductions  in  military 
force  levels  throughout  NATO  nations  and  environmental  impact  and  resulting  pressures  from  live 
exercises.  A  major  tenet  of  NATO  training  is  that  CAX  does  not  totally  replace  the  need  for  live  exercises, 
but  does  enable  a  reduction  in  the  number  and  scope  of  exercises  involving  the  deployment  of  troops.  The 
value  of  CAX  is  particularly  important  in  training  senior  level  commanders  and  their  staffs  in  executing 
complex  operational  orders  involving  multi-national  force  elements. 

Although  the  requirement  for  a  NATO  CAX  capability  was  established  in  1992,  the 
implementation  of  a  NATO-owned  CAX  capability  has  been  a  slow  and  difficult  process.  Initially,  NATO 
made  use  of  simulation  and  modeling  capabilities  in  the  U.  S.  Warrior  Preparation  Center  (  WPC  )  at 
Ramstein  Air  Force  Base  in  Germany.  At  present,  both  the  WPC  and  the  NC3A  in  The  Hague,  NL  execute 
CAX  programs. 
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NATO's  CAX  capabilities  are  evolving  and  will  continue  to  do  so  for  several  years.  At  the  top 
command  level,  a  candidate  model  is  the  U.S.  Joint  Theater  Level  Simulation  (JTLS)  model.  This  model 
is  the  one  executed  by  both  the  WPC  and  the  NC3A  for  NATO  training  purposes.  There  are  also  other 
models  in  use,  including  a  Swedish  theater  level  model  used  at  the  PfP  Simulation  Center. 

For  future  CAX  capabilities,  SHAPE  has  formed  a  Multi-National  Working  Group  which  is 
formulating  plans  for  a  CAX  program  oriented  toward  the  NATO  Combined  Joint  Task  Force  concept  in  a 
multi-national  environment. 

NATO  requires  nations  including  Slovakia  to  have  some  initial  capability  to  participate  in  training 
exercises.  The  primary  focus  of  computer-assisted  exercises  will  be  on  the  conduct  of  operations  and  on 
the  logistics  support  for  national  forces  involved  in  such  operations.  Within  those  guidelines,  however, 
nations  may  choose  to  implement  whatever  simulation  models  are  appropriate  to  aid  in  meeting  national 
training  requirements.  At  some  point  in  the  future,  it  will  become  desirable  or  necessary  to  conduct 
computer-assisted  simulations  on  a  distributed  basis,  with  several  nations  and  NATO  participating  jointly. 
In  preparation  for  such  joint  CAX  activity,  it  is  recommended  that  nations  use  models  that  are  either 
identical  to  or  substantially  the  same  as  those  used  by  NATO.  It  is  assumed  that  for  such  purposes,  NATO 
will  provide  simulation  models  supporting  training  for  multi-national  coalition  operations  to  all  nations 
required  to  participate  in  NATO  coalition  computer-assisted  exercises. 

A  requirement  for  conducting  distributed  simulations  is  the  ability  to  exchange  information 
between  different  models  or  between  identical  models  executing  at  different  locations.  To  enable  this 
exchange  of  information,  several  nations  in  the  SHAPE  Multi-National  Working  Group  mentioned  above 
have  been  connecting  several  national  simulations,  which  are  currently  integrated  using  the  Aggregate 
Level  Simulation  Protocol  (ALSP).  ALSP  includes  a  standardized  structure  for  representing  military  force 
elements  (e.g.,  tanks,  aircraft,  etc.)  and  for  describing  their  operating  parameters.  The  use  of  ALSP  enables 
a  specific  simulation  scenario  (forces,  equipment,  fuel,  logistics  supplies,  etc.)  to  be  transferred  between 
similar  simulation  models.  In  this  manner,  portions  of  an  operational  situation  may  be  conducted  by  one 
participant  (e.g.,  nation)  in  a  distributed  simulation  and  the  results  transferred  to  a  different  participant  for 
other  portions  to  be  conducted.  Results  from  the  national  distributed  simulation  experiments  indicate  that 
ALSP  is  useful  but  that  the  newer  simulation  integration  standard  called  the  High  Level  Architecture  or 
HLA  would  be  more  effective.  NATO  has  adopted  HLA  as  the  standard  interface  between  new 
simulations,  and  plans  for  use  of  HLA  are  being  developed  in  the  Working  Group. 

Future  requirements  can  be  anticipated  for  interfacing  a  national  CAX  host  computer  with  NATO 
CAX  systems  executing  on  CCIS  servers.  At  present  interoperability  between  national  and  NATO  CCIS 
systems  will  require  remote  NATO  CCIS  terminals  in  national  HQ  locations.  NATO  presently  requires 
isolation  of  NATO  CCIS  terminals  from  national  CCIS  computer  terminals  by  "air-gap"  interfaces. 
Eventually,  security  Guards,  developed  and  approved  for  specific  applications,  will  enable  national  and 
NATO  CCIS  systems  to  be  physically  interconnected.  Once  satisfactory  Guard  devices  are  available  and 
implemented,  it  may  be  possible  to  interface  CAX  models  with  national  and  NATO  CCIS  systems. 

The  major  operational  functions  supported  by  CAX  are: 

•  Air  operations  and  training 

•  Land  operations  and  training 

•  Movement  planning  and  coordination 

The  system  components  of  Slovakia/NATO  CAX  interconnection  are  illustrated  in  Figure  1.  The 
interconnection  will  be  similar  for  Slovakia  participation  in  a  NATO-hosted  CAX  or  NATO  participation 
in  a  Slovakia-hosted  national  CAX. 
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NATO  HQ 


Slovakia 


Level  3  Interconnection 


Figure  1.  CAX:  System  Components-Near  Term 


After  Slovak  membership  in  the  year  2004,  it  is  likely  that  NATO  would  extend  the  NATO  IP 
router  into  Slovakia  and  install  capabilities  for  Slovakia  to  support  classified  email  exchanges  with  NATO 
subscribers.  Provision  of  an  ACE  ACCIS  terminal  would  give  Slovakia  an  initial  connectivity  with  NATO 
CAX  information. 

It  is  expected  that  Slovakia  operates  its  own  CAX  capability  separately  from  NATO  using  an  air 
gap  interface.  This  is  NATO  Level  3  interconnection  between  systems. 

In  the  far  term,  it  would  be  possible  to  migrate  to  a  configuration  where  a  Slovak  CAX  system 
could  be  connected  to  NATO  systems  through  an  approved  Guard  to  achieve  NATO  Level  4 
interconnection,  as  shown  in  figure  2. 


NATO  HQ  Slovakia 


Figure  2.  CAX:  System  Components-Far  Term 
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Simulation  Federation  and  Pre-NATO  Accession 


In  the  period  before  NATO  accession,  Slovakia  already  have  developed  its  capability  to  engage  in 
internal  (domestic)  CAX.  The  first  step  in  this  was  to  acquire  or  develop  the  necessary  hardware  and 
software.  Computer  models  are  in  accordance  with  NATO  standards  wherever  possible.  Slovakia 
requested  releasable  interface  standards  through  US  FMS  program  and  coordination  cell.  The  initial  goal 
was  providing  this  training  capability  to  the  Slovak  restructured  Armed  Forces  earmarked  for  participation 
in  NATO  activities.  Interfaces  into  domestic  C3I  systems  drive  design  considerations. 

The  OS  SR  is  currently  reviewing  the  use  of  both  C3I  systems  LETVIS  and  the  ASOC;  there  may 
be  possible  cost  savings  if  only  one  system  used.  However,  there  are  more  than  300  LETVIS  workstations 
located  throughout  the  OS  SR.  LETVIS  will  also  be  used  as  hackup  for  the  civil  ATC  system  and  training 
within  Simulation  Federation.  LETVIS  processes  radar  data,  tracks,  flight  plans,  and  wealher  information 
in  reality  or  for  training  purpose  fictive,  simulated  inputs  and  it  transmits  tracks  and  flight  plans  to  the 
ASOC, 

The  ASOC  is  located  at  the  Combat  Command  Center.  It  is  currently  used  only  for  training  and 
testing.  There  are  plans  to  transition  to  an  eight-hour/day  operation  if  additional  positions  can  be  funded  in 
the  new  year.  The  ASOC  provides  the  capability  to  process  radar  data,  tracks  and  flight  plans.  The  OS  SR 
plants  lo  use  the  ASOC  for  exchange  of  information  with  regional  ASOCs  (in  accordance  with  bilateral 
and/or  multilateral  agreements).  The  ASOC  has  also  a  link  capability. 

Given  the  LETVIS  system  current  widespread  deployment  and  capability,  the  OS  SR  will  continue  to  use 
LETVIS  as  the  primary  air  surveillance  system.  The  ASOC  will  be  retained  and  maintained  for 
information-sharing  with  regional  ASOCs/NATO  systems.  By  doing  so,  the  technical  capabilily  is 
retained  to  exchange  information  with  similar  systems  once  the  necessary  political  agreements  are 
arranged.  In  order  to  fully  support  future  information  sharing  with  neighboring  countries,  the  OS  SR 
should  operate  the  link  between  the  ASOC  and  LETVIS  as  a  two-way  link.  An  added  benefit  is  that  the 
ASOC  has  western-style  air  defense  C3I  attributes  that  can  be  used  for  training  in  simulated  environment 
for  coalition  deployments. 

OSSR  also  participates  in  the  SHAPE/NATO  C3  Agency  "Cooperative  Automation"  and  other 
seminars  to  familiarize  PfP  nations  with  CAX  capabilities.  Additionally,  OSSR  participate  in  PfP 
Simulation  Network  (PSN)  exercises.  The  PfP  training  center  in  Sweden  will  host  a  distributed  war 
gaming  exercise  facility.  These  exercises  are  expected  to  be  open  to  participation  by  both  NATO  members 
and  PfP  nations  including  Slovakia. 

In  order  to  execute  NATO  and  national  simulation  models,  nations  are  required  to  provide 
adequate  computer  facilities.  Specific  requirements  for  computer  systems  are  coordinated  with  SHAPE. 
However,  in  general,  high  end  Pentium  PCs  and/or  HP  with  extensive  RAM  and  hard  drive  capacities  are 
in  operation.  It  may  be  necessary  to  use  UNIX  machines  in  some  cases. 

Post-NATO  Accession 

After  NATO  accession,  Slovakia  also  will  need  capability  to  participate  in  NATO  war  gaming 
exercises  for  units  down  to  the  brigade  level.  Initially,  this  capability  will  consist  of  a  remote  terminal  to 
provide  an  extension  of  the  NATO  CGIS  system  (ACE/ACCIS).  This  will  represent  a  level  3  (air  gap) 
interconnection  with  NATO  systems.  At  some  point  in  the  far  term,  an  interface  between  NATO  and 
Slovak  systems  may  be  implemented  as  security  permits. 

In  today's  world  of  decreasing  sizes  of  military  forces,  countries  are  relying  on  information  as  a 
significant  force  multiplier.  Key  to  this  concept  is  the  use  of  automated  systems  to  process  and  exchange 
information.  As  discussed  above,  the  OS  SR  has  few  C3  Information  systems  currently  in  operation, 
particularly  systems  that  support  the  automatic  exchange  of  information.  The  OS  SR  is  planning  to 
develop  new  C3  information  systems  and  to  integrate  them  with  existing  training  simulation  tools  in  a 
Global  Information  System  (GLOBIS)  architecture.  The  GLOBIS  architecture  will  incorporate  and 
interconnect  information  systems  from  many  areas  within  the  OSSR. 
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Slovakia  will  also  continue  to  implement,  through  acquisition  or  internal  development,  the 
capability  to  participate  in  distributed,  NATO-led  Computer  Assisted  Exercises.  The  initial  capability 
should  be  designed  to  support  internal  requirements.  This  means  that  concentration  will  be  given  to 
providing  interfaces  to  internal  (domestic)  systems.  In  addition  to  the  obvious  benefits  derived  from  any 
training  capability,  this  will  provide  Slovak  officers  the  classroom  for  developing  experience  with  CAX 
techniques. 

Slovakia  was  provided  with  tactical  level  of  CAX  training  model  as  ModSAF  (OTB)  but  is  this 
period  should  obtain  an  operational  level  command  CAX  training  model  as  Joint  Theater  Level  Simulation 
(JTLS),  WarSIM,  JSIM  or  NASM  models. 

The  following  requirements  checklist  will  assist  the  OSSR  in  evaluating  its  Simulation  Federation 
development  program. 

•  Has  the  nation  requested  CAX  software  and  training  from  NATO? 

•  Has  the  nation  participated  in,  or  is  the  nation  prepared  to  participate  in,  the  Cooperative 

Automation  seminars  given  annually  by  SHAPE/NC3A? 

•  Does  the  nation  currently  use  some  form  of  simulation  model  to  provide  CAX  training  for  national 
command  and  logistics  operations? 

•  Are  the  nation's  contributed  forces  equipped  with  suitable  computer  systems  for  the  purpose  of 
executing  distributed  CAX  simulation  models  on  national  and  NATO  CIS  systems  and 
exchanging  results  in  a  near  real-time  mode? 

Promising  vision 

In  conclusion,  only  very  efficient  professional  Slovak  Armed  Forces  and  stabile  democratic 
political  environment  create  the  best  platform  for  establishment  of  the  Simulation  Federation  within 
integration  of  now  existing  or  in  future  considered  C3I  ATC  Systems  in  the  frame  of  NATO  membership 
under  real  promising  vision  to  become  a  valid,  credible  NATO  partner  and  member. 
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SUMMARY 

Joint  Theater  Level  Simulation  (JTLS)  [6-12]  is  the  constructive  simulation  used  to  support 
joint/combined  exercises  at  operational  and  higher  levels  in  Turkish  Armed  Forces.  However,  JTLS  does 
not  fit  all  the  requirements  in  these  exercises.  The  tactical  considerations  may  sometimes  have  a  major 
impact  on  the  decisions  at  higher  levels.  Especially,  the  resolution  of  terrain  data  does  not  allow 
simulating  the  required  tactical  details  in  JTLS.  Moreover,  participants  of  an  exercise  should  interact  with 
a  simulation  by  using  either  real  or  realistic  C2  systems.  The  standard  user  interfaces  of  JTLS,  namely 
GIAC  [1-5],  MPP  and  1MT,  cannot  emulate  these  C2  systems  in  most  of  the  cases.  During  the  game,  all 
the  participants  that  use  standard  JTLS  interfaces  have  the  same  perception  of  the  operational  picture  if 
they  are  at  the  same  side.  This  is  not  very  realistic.  JTLS  cannot  provide  multiple  perceptions  for  the  same 
side.  HOGAY  is  a  generic  graphical  interface  and  filtering  system  developed  to  minimize  these 
weaknesses  of  JTLS.  In  this  paper  we  introduce  the  architecture  of  HOGAY,  and  the  method  to  propagate 
data  in  HOGAY. 


1.0  INTRODUCTION 

Unless  the  constructive  simulations  are  supported  by  appropriate  user  interfaces,  they  cannot  fulfill  the 
basic  requirements,  e.g.,  better  immersion,  being  realistic,  etc.,  of  a  computer  aided  exercise  (CAX).  If  a 
realistic  perception  of  the  common  operational  picture  cannot  be  provided  to  the  users  based  on  their  side, 
level  in  the  command  hierarchy,  communications  tools  and  environment,  the  users  cannot  be  satisfied 
even  if  the  most  complex  and  realistic  combat  models  are  used  to  calculate  the  attrition  and  mobility  of 
units.  Therefore,  user  interfaces  are  at  least  as  important  as  combat  models  in  military  constructive 
simulations. 

Joint  theater  level  simulation  (JTLS)  has  some  shortcomings  in  this  respect.  In  JTLS  every  terminal  that 
belongs  to  the  same  side  has  the  same  view  for  the  common  operational  picture.  Every  terminal  of  the 
same  side  learns  about  a  unit  as  soon  as  any  sensor  of  that  side  detects  it.  When  the  detection  is  fused,  all 
the  details  related  to  the  detected  unit  become  available  for  the  detecting  side.  This  can  make  unrealistic 
impacts  on  the  results  of  an  exercise.  A  submarine  commander  can  engage  a  surface  ship  more  than  100 
km  away  as  soon  as  it  is  detected  by  a  patrol  boat,  which  does  not  have  any  link  system.  The  graphical 
wargame  interface  application  introduced,  HOGAY,  has  been  developed  to  overcome  these  difficulties 
caused  by  the  user  interfaces  used  in  JTLS. 

There  are  four  factors  affecting  the  design  of  HOGAY : 

i)  Requests  of  users:  Players  prefer  to  interact  with  JTLS  using  GUIs  (Graphical  User  Interfaces)  similar  to 
real  C2  systems.  Requirements  may  change  depending  on  the  service  that  the  player  belongs  to. 

Paper  presented  at  the  MSG-022/SY-003  Conference  on  "C3I  and  M&S  Interoperability  ”, 
held  in  Antalya,  Turkey,  9-10  October  2003,  and  published  in  RTO-MP-MSG-022. 
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ii)  Interaction  with  JTLS  by  using  a  single  program:  Currently,  the  player  interact  with  JTLS  by  using  four 
programs,  namely  GIAC  (Graphical  Interface  Aggregate  Control),  MPP  (Message  Processor  Program), 
IMT  (Information  Management  Tool),  and  OPM  (Online  Player  Manuel).  The  interface  program 
developed  will  perform  the  functions  of  all  these  programs. 

iii)  Visualization  of  detection/fusion  information  with  a  propagation  delay:  Currently,  detection/fusion 
information  is  obtained  instantly  by  all  the  players  of  the  detecting  side.  However,  this  information  shoidd 
propagate  with  respect  to  the  delay  parameters  between  unit  pairs.  Moreover,  it  should  also  be  possible  to 
form  links  among  some  units.  Information  obtained  by  a  linked  unit  is  immediately  passed  to  the  other 
units  under  the  same  link  without  considering  physical  distance  among  them. 

iv)  A  list  of  utilities  prepared  by  the  users  of  the  other  interfaces  is  also  taken  into  consideration. 

The  paper  is  organized  as  follows:  In  Section  2,  the  system  architecture  of  HOGAY  is  explained.  Section  3 
introduces  Model  Client  Interface,  and  basic  processes  implemented.  Propagation  of  information  and 
filtering  is  detailed  in  Section  4.  Section  5  introduces  Player  and  Controller  Interfaces.  Finally,  Section  6 
concludes  the  paper. 


2.0  GENERAL  ARCHITECTURE  OF  HOGAY 

There  are  three  basic  units  forming  HOGAY,  namely  Player  Interface  (PI),  Controller  Interface  (Cl),  and 
Model-Client  Interface  (MCI).  There  is  a  dedicated  MCI  for  the  players  of  each  side.  These  are  names  as 
MCI-PI-violet,  MCI-PI-orange,  etc.  Moreover,  there  is  an  MCI  for  the  controllers  called  MCI-CI.  Players 
use  Pis  to  interact  with  JTLS.  Cl  is  a  PI  with  some  privileges.  It  can  fetch  data  for  all  sides  and  send  some 
special  administrative  orders  to  JTLS  and  MCI.  MCI  is  an  interface  between  JTLS  and  end-users  (players 
and  the  controller).  Pis  and  CIs  work  on  the  Windows  environment.  They  are  developed  by  using  Visual 
C++  and  Delphi.  MCI  is  implemented  on  Unix  by  using  the  C  programming  language. 
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HOGAY  has  two  more  components  also  developed  in  UNIX  environment  by  using  the  C  programming 
language:  GENIS-COM  and  MPP-COM.  These  components  are  included  in  the  system  design  to  improve 
the  interoperability  and  reusability  of  HOGAY.  MCI,  PI  and  Cl  are  independent  from  JTLS  and  other 
military  simulation  systems.  These  components  use  an  application  layer  protocol  designed  for  HOGAY  to 
communicate.  GENIS-COM  and  MPP-COM  also  use  the  same  protocol  to  communicate  with  MCI  and/or 
CIs  and  Pis.  On  the  other  hand,  GENIS-COM  and  MPP-COM  uses  standard  GENIS  libraries  to  pass 
messages  to  or  from  GENIS.  Therefore,  adapting  HOGAY  to  the  version  changes  in  JTLS  is  only  limited 
to  modifying  GENIS-COM  and  MPP-COM  which  are  also  HLA  compliant. 


3.0  MODEL  CLIENT  INTERLACE  (MCI) 

MCI  is  a  parallel  processing  program  responsible  from  transmitting  the  GENIS  data  to  PI-CI  modules  and 
the  PI-CI  orders  to  GENIS.  There  is  a  dedicated  MCI  for  the  players  of  each  side.  The  MCI  of  a  given  side 
downloads  the  data  specific  to  its  side.  MCI-C1  downloads  data  for  all  sides  and  presents  this  data  without 
any  delay.  MCI-CI  also  modifies  the  delay  information  related  to  the  propagation  of  information  among 
units  based  on  the  orders  given  by  the  controllers. 

The  MCI  software  consists  of  three  fundamental  processes  and  two  supplementary  processes  for  each  new 
client  connection,  as  shown  in  Figure  2.  The  fundamental  processes  are  the  Main,  GenisComm  Reader 
and  Updater  processes.  Main  does  the  elementary  operations  and  initiates  the  required  processes  for  each 
new  client  connection.  Genis  Comm  Reader  is  the  process  responsible  of  listening  the  GENIS  socket  and 
storing  the  incoming  data.  Updater  updates  the  MCI  data  to  be  send  to  PI/CI  modules.  Main  creates  two 
new  processes  PIreader  and  Plwriter  for  each  new  client  connection.  PIreader  receives  the  orders 
coming  from  the  interface  modules  PI/CI  and  sends  them  to  OVT.  Pl  writer  sends  the  MCI  data  to  the 
related  interface  module. 
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4.0  PROPAGATION  OF  INFORMATION 

One  of  the  most  important  contributions  of  HOGAY  is  the  filtering  module  implemented  in  MCI  and  Pis. 
To  pace  with  the  changes  in  the  game,  its  implementation  is  distributed  between  these  two  modules.  Here 
a  sample  scenario,  shown  in  Figure  3,  is  given  to  describe  the  filtering  operation.  In  this  sample  scenario 
there  are  three  players  named  01,  02  and  03.  Players  are  thought  of  as  virtual  units  with  zero  delay  values 
to  the  units  under  their  authority.  In  this  scenario,  01  and  02  have  two  units  under  their  command  and  03 
has  one  unit  under  his  command.  Units  are  named  B1  to  B5. Delays  between  units  are  defined  as  GXY. 
(Here  X  and  Y  represent  unit  indexes.)  For  example  delay  between  B1  and  B3  is  defined  as  G 13. There  are 
two  relationships: 

•  Player-Unit  Relationship 

•  Unit-Unit  Relationship 

A  player  can  have  more  than  a  single  unit  under  his/her  control.  For  example  player  01  controls  units  B1 
and  B2.  Detections  that  reach  to  these  units  or  the  detections  made  by  these  units  should  be  visible  without 
any  delay  in  the  PI  of  01.  On  the  other  hand,  the  other  units  can  learn  the  detections  made  by  units  after  a 
delay  based  on  some  parameters  such  as  the  position  of  units  in  the  command  hierarchy,  the 
communications  capabilities,  jamming,  links,  and  the  distance  between  units.  Delays  between  units  are 
kept  in  a  dynamic  database.  Delay  values  can  be  changed  by  the  controller  during  the  game. 


When  MCI  is  run  for  the  first  time,  or  when  the  unit-to-unit  or  player-to-unit  relations  are  changed,  the 
shortest  delay  path  between  the  units  and  players  are  calculated  by  using  Floyd’s  all  pair  shortest  path 
algorithm,  and  the  results  are  kept  in  a  matrix  called  Floyd-Matrix.  Since  Floyd’s  algorithm  is  a  time 
consuming  one,  0(N3),  it  is  assumed  that  the  matrix  is  symmetrical,  i.e.  GXY  is  equal  to  GYX.  When  a  PI 
connects  to  an  MCI,  the  row  related  to  the  player  of  the  PI  from  Floyd-Matrix  is  downloaded  to  the  PI. 
This  delay  information,  which  gives  the  delay  between  any  unit  in  the  simulation  and  the  player,  is 
updated  every  time  when  the  related  row  in  the  delay  matrix  in  MCI  is  modified. 

Pis  do  not  reflect  every  update  to  the  player  as  soon  as  they  receive  it  from  MCI.  First  they  determine  how 
long  does  it  take  to  convey  this  update  to  the  player  based  on  the  delay  values.  PI  finds  out  the  source  unit 
of  the  update.  If  it  is  an  update  about  a  friend  unit,  that  friendly  unit  is  the  source.  However,  when  this  is  a 
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detection  data,  or  an  update  about  an  enemy  unit,  PI  needs  to  find  the  detecting  unit.  In  HOGAY  this  is 
done  by  checking  the  location  of  the  detected  data  against  the  ranges  of  open  sensors  available  in  the 
friend  forces.  The  closest  owner  unit  of  one  of  these  sensors  that  can  make  the  detection  is  accepted  as  the 
source  unit.  After  this  point  it  is  only  a  lookup  in  the  delay  relations  data,  which  is  determined  by  related 
row  of  Floyd-matrix  to  find  out  the  required  delay  for  the  update  in  the  operational  picture  of  the  unit.  The 
updates  are  inserted  into  a  linked  list  based  on  their  update  time  determined  by  using  these  delays,  and 
made  available  to  the  player  as  their  time  come. 

Filtering  can  also  be  bypassed,  i.e.  when  an  information  update  of  a  friend  or  enemy  unit  has  arrived,  it  is 
shown  on  the  player’s  screen  directly  without  any  delay. 


5.0  PLAYER/CONTROLLER  INTERFACE 

PI  is  the  interface  unit  that  displays  the  propagated  simulation  data  downloaded  from  MCI  via  TCP/IP.  PI 
is  the  integrated  form  of  GIAC,  IMT,  MPP,  OPM.  It  includes  all  the  options  of  these  programs  and  more. 
Architecture  of  PI  is  composed  of  four  DLLs  and  the  main  graphical  interface  program,  as  in  Figure  4. 


PI 


Figure  4:  Architecture  of  Player  Interface 


GDataATL  is  a  COM  DLL  implemented  by  using  Visual  C++.  This  module  connects  to  MCI  to  download 
the  simulation  data  and  stores  the  updated  version  of  simulation  data.  The  filtered  data  is  fired  to  graphical 
interface  when  triggered  with  time  packets.  Communication  architecture  of  GDataATL  is  given  in  Figure 
5. 


parameters 
and  orders 


parameters 
and  orders 


Figure  5:  Communication  Architecture  of  GDataATL 
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MPPATL  is  also  a  COM  DLL  implemented  by  using  Visual  C++.  MPPATL  connects  to  MPP-COM  and 
fires  the  incoming  messages  to  the  graphical  interface.  CustomSymbols  is  a  COM  DLL  designed  for 
drawing  the  unit  symbols  in  the  graphical  interface.  This  module  is  also  implemented  by  using  Visual 
C++.  CustomRenderer  is  also  a  COM  DLL  implemented  by  using  Visual  Basic.  CustomRenderer  is  used 
to  draw  user  and  unit  lines,  save  or  load  them  in  layers. 

Graphical  Interface  is  the  basic  interface  developed  in  Delphi.  In  Figure  6,  PI  and  GIAC  screens  are 
shown.  At  the  first  glance,  both  of  them  are  quite  similar.  The  main  difference  is  that  PI  uses  raster  maps 
while  GIAC  uses  hexagonal  maps.  Apart  from  this,  all  the  information  panes,  buttons,  and  windows  are 
collocated  in  a  dockable  window  in  PI.  This  window  can  be  dragged  into  any  place,  resized  or  minimized 
as  needed.  The  order  menus  and  the  other  menus  are  also  positioned  as  in  a  standard  windows  application. 
Hence,  it  is  easier  to  train  the  operators  which  are  used  to  working  in  MS  Windows  environment. 

PI  has  all  of  the  utilities  available  in  GIAC  e.g.,  unit  and  user  lines,  display  options,  filtering  options, 
panning,  zooming,  etc.  Apart  from  them,  it  has  some  additional  tools  designed  based  on  the  lesson  learned 
from  the  previous  exercises.  For  example,  three  C2  systems,  namely  ICC,  STACOS  and  a  new  C2  system, 
are  implemented  in  PI.  User  selects  one  of  them,  and  the  screen  looks  like  the  screen  of  the  selected  C2 
system.  This  does  not  change  the  tool  bar  or  the  menu  but  only  the  operational  picture  is  shown  in  a  screen 
that  looks  like  the  screen  of  the  selected  C2  system.  Another  important  new  tool  is  Local  Tracks  which  are 
virtual  units  created  by  players  to  demonstrate  probable  units  at  that  location.  Local  tracks  can  be  created, 
deleted,  moved  or  shared  with  other  players.  This  new  utility  will  be  very  useful  in  the  detection/fusion 
steps  or  in  electronic  war  models. 


Figure  6:  PI  and  GIAC  Screens 


The  navigation  on  the  map  is  also  easier  in  PI  where  the  location  of  the  current  screen  in  overall  theatre  is 
also  shown  in  a  navigation  window.  It  is  also  possible  to  find  out  the  length  of  a  river  or  road  as  shown  in 
the  dockable  information  window  in  Figure  7.  Another  important  tool  available  in  PI  is  a  very  realistic 
three-dimensional  (3D)  flight  simulator.  Some  screens  from  this  real  time  flight  simulator  are  shown  in 
Figure  8.  These  screens  are  generated  by  using  standard  DTED  formatted  digital  maps,  satellite  pictures 
and  some  additional  data  related  to  terrain  features  and  textures. 
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Figure  7:  PI  Utilities 


Figure  8:  The  Screens  from  the  3D  Flight  Simulator  of  PI 

PI  also  presents  a  window  where  the  information  about  the  units  and  other  assets  in  the  theatre  in  tabular 
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form.  This  tool,  which  is  an  enhanced  version  of  IMT  used  in  standard  JTLS  configuration.  Another  tool  is 
the  equivalent  of  MPP  in  JTLS  where  the  users  can  see  the  messages  generated  by  JTLS  for  them.  Users 
send  their  orders  to  JTLS  also  by  using  templates  similar  to  the  ones  in  JTLS.  With  all  of  these  utilities 
HOGAY  will  become  the  standard  user  interface  for  the  constructive  simulation  systems  used  in  Turkish 
Armed  Forces. 

Cl  and  PI  are  the  same  programs.  During  the  authentication  stage  order  menus  are  dynamically  created 
according  to  the  user’s  type.  So  the  only  visual  difference  is  the  orders  they  can  give.  Cl  is  connected  to 
MCI-CI  to  get  the  whole  simulation  data  without  filtering  in  GDataATL  if  the  user  is  logged  as  a 
controller. 


6.0  CONCLUSIONS 

HOGAY  is  an  interface  system  which  can  connect  to  JTLS,  and  provide  users  with  filtered  perceptions 
based  on  command  hierarchy  and  propagation  delay.  Available  C2  systems  in  the  Turkish  Armed  Forces 
are  also  emulated  in  HOGAY.  Hence,  exercise  participants  are  better  immersed  into  situation,  and  more 
realistic  joint  exercises  can  be  conducted.  HOGAY  has  also  many  new  utilities  which  makes  the  players 
learn  how  to  use  it  easier  and  operate  it  more  effective.  It  was  first  used  in  a  major  exercise  in  2003. 
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SUMMARY 

The  concept  of  a  future  Modelling  and  Simulation  Network  is  based  on  a  methodology  of  knowledge  and 
information  management.  In  the  framework  of  this  methodology  the  Integrated  Army  M&S  Data  Network 
will  be  established  as  an  operational  and  technical  concept  to  allow  knowledge  transfer  between 
operational  headquarters,  study  facilities,  procurement  agencies  and  training  installations. 

The  Concept  of  the  Integrated  Army  M&S  Data  Network  has  the  following  objectives: 

•  Efficient  data  acquisition,  processing  and  administration  for  a  Modelling  and  Simulation 
environment, 

•  Data  exchange  between  simulation  systems  and  possible  data  sources  (other  simulation  systems,  C4I- 
systems,  databases,  etc.)  based  on  a  common  information  language, 

•  Installation  of  a  common  data  management  process  to  define,  establish  and  administer  a  common 
information  language 

The  represented  results  reflect  a  series  of  substantial  studies  conducted  by  civil  contractors.  Special 
thanks  go  to  Dr.  Stefan  Krusche,  Mr.  Peter  Arwanitis  and  Mr.  Ralf  Pfrogner,  IABG  GmbH,  Munich  for 
their  outstanding  work  on  this  subject. 

1  MODELLING  AND  SIMULATION  INLORMATION  DOMAIN 
1.1  Situation 

Modelling  and  Simulation  (M&S)  is  the  generic  term  for  operations  research  methods,  the  application  of 
simulation  in  training  and  exercises  as  well  as  the  simulation  technology.  M&S  includes  the  provision  and 
use  of  methods,  models,  scenarios  and  data  in  the  areas  of 

•  analysis  and  planning 

•  training  and  exercises 

•  research,  technology  and  acquisition  as  well  as 

•  support  to  military  operations. 

The  goals,  based  on  the  conceptual  Army  Guidelines,  are: 
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•  optimisation  and  comprehensive  development  approach  over  the  application  areas, 

•  linkage  with  the  Army  IT  System,  especially  with  the  functional  and  command  and  control  systems, 

•  modular  driven  architecture  in  the  framework  of  an  integrated  system  of  models  and  methods, 

•  in-time  provision  of  the  best  available  and  usable  data. 

One  of  the  unconditional  key  aspects  of  the  Concept  of  the  Integrated  System  of  Systems  M&S  is  the 
realisation  of  a  corporated  Information  Management. 

Nowadays  the  existing  legacy  systems  are  tailored  to  the  requirements  of  the  relevant  application  domains. 
Systems  developers  use  their  own  individual  concept  of  information  representation.  Often  these 
information  concepts  are  inadequately  documented,  hidden  in  the  program  code  or  in  the  graphic  user 
interface.  Therefore  the  customisation  and  integration  of  legacy  systems  in  a  system  of  systems  is  either 
technically  impossible,  economically  not  acceptable  or  at  a  semantic  and  pragmatic  level  faulty. 

The  Integrated  Army  Modelling  and  Simulation  Data  Network  defines  a  technical  framework  for  the 
integration  of  OR-systems,  modules  and  methods  in  a  M&S  system  of  systems  based  on  information 
management  principles. 

The  information  management  process  in  an  M&S  network  has  its  peculiarities  and  three  domains  of 
support  can  be  identified: 

•  Method  development, 

•  System  /  Module  interoperability  and 

•  Comprehensive  Information  Provision. 

1.2  Modelling  Process 

All  phases  of  the  modelling  process  require  support  by  a  multi  -  functional  information  network. 

The  System  Analysis  Phase  is  based  on  knowledge  about  the  “real  world”.  Agreed  concepts,  doctrines  and 
experience  based  knowledge  (e.g.  Lessons  Learned,  Case  Studies,  Best  Practise)  are  the  baseline  for  a 
conceptual  model.  In  the  next  phase  the  conceptual  model  has  to  be  formalised  by  using  generic  modelling 
methods.  The  formal  model  defines  parameters  and  their  relations.  Often  these  parameters  require 
processed  information  based  on  field  tests,  results  of  high  resolution  models,  method  requirement 
(Lancaster-coefficient,  Killer-Victim-tables,  Meantime  failure  by  time) 

Particularly  for  the  integration  in  a  standardised  M&S  framework  the  new  model  has  to  be  harmonised 
with  the  procedural,  methodical  and  technical  guidelines  of  the  system  framework  and  its  components. 

The  requirements  for  a  “Developers  Information  Network”  are 

•  access  to  all  standardised  conceptual,  formal  and  technical  products  and  related  documentation; 

•  access  to  unstructured  information  (e.g.  doctrines,  concepts,  study  reports); 

•  information  collection  and  processing  with  respect  to  the  model  parameters  and  the  problem 
definition; 

•  predefined  model  documentation  guidelines  incorporating  the  complete  modelling  process  (incl. 
assumptions  and  restraints,  information  concepts,  information  requirements,  stability,  interpretation, 
validation). 
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1.3  System  Interoperability 

From  the  analytical  perspective  problem  oriented  individual  solutions  are  more  appropriate  then 
standardised  methods  with  a  wide  operative  range.  Flowever  it  might  be  necessary  to  split  complex  models 
into  interoperable  micro-systems  or  modules.  Also  the  integration  of  standardised  common  application 
services  like  scenario  generators,  terrain  visualisation,  data  bases  and  evaluation  tools  requires 
interoperability  guidelines. 

In  order  to  classify  Interoperability,  the  ISC  has  included  in  their  NATO  Policy  for  C3  Interoperability 
(P0(2000)39),  four  degrees  of  interoperability  as  follows: 

•  Degree  1 :  Unstructured  Data  Exchange.  Involves  the  exchange  of  human- interpretable  unstructured 
data  such  as  the  free  text  found  in  operational  estimates,  analyses  and  papers. 

•  Degree  2:  Structured  Data  Exchange.  Involves  the  exchange  of  human-interpretable  structured  data 
intended  for  manual  and/or  automated  handling,  but  requires  manual  compilation,  receipt  and/or 
message  dispatch. 

•  Degree  3:  Seamless  Sharing  of  Data.  Involves  the  automated  sharing  of  data  amongst  systems  based 
on  a  common  exchange  model. 

•  Degree  4:  Seamless  Sharing  of  Information.  An  extension  of  degree  3  to  the  universal  interpretation  of 
information  through  data  processing  based  on  co-operating  applications. 

The  realised  level  of  interoperability  depends  on  the  use  case. 

In  a  system  of  systems  four  levels  of  interoperability  were  identified  which  are  a  pre-condition  to  reach  a 
certain  interoperability  degree. 

•  Level  1 :  Technical  Information  Exchange  (You  are  able  to  talk) 

•  Level  2:  Syntactic  Information  Exchange  (You  are  able  to  talk  grammatically  correctly) 

•  Level  3:  Semantic  Information  Exchange  (Everybody  knows  what  you  talk  about) 

•  Level  4:  Pragmatic  Information  Exchange  (You  act  logically  on  a  common  understanding) 

In  most  cases  the  technical  levels  1  and  2  can  be  realised.  Due  to  the  semantic  diversity  of  legacy  systems 
in  Level  3  and  4  the  validity  of  linked  systems  can  be  challenged  in  most  cases. 

1.4  Comprehensive  Information  Provision 

Within  a  M&S  network  the  organisational,  data  and  procedural  view  of  information  provision  determine 
the  design  of  a  future  Information  Management  System.  Based  on  a  modern  Data  Warehouse  architecture 
the  Information  Management  System 

•  decouples  and  processes  “raw  information”  from  operative  databases  of  external  information  sources 
into  system  specific  Data  Views  or  Marts, 

•  provides  processing  functions  like  aggregation,  deaggregation,  filtering  and  statistic  evaluation  as  well 
as  plausibility  and  consistency  checks, 

•  reflects  various  information  concepts  of  heterogeneous  OR  Systems  and  their  data  storage, 

•  provides  information  access  within  a  decentralised  organisational  structure  of  the  M&S  community. 

Information  Logistic  via  a  Data  Warehouse  can  improve  quality,  integrity  and  consistency  of  the  required 
information. 
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Figure  1:  M&S  Information  Model 


2  INFORMATION  MANAGEMENT 

As  a  result  of  the  transition  from  the  industrial  to  the  information  age  knowledge  represents  an  inherent 
value  within  an  organisation.  Therefore  Knowledge  Management  focuses  on  an  efficient  provision  and 
mission  oriented  usage  of  knowledge  for  an  optimised  decision  support  inside  an  organisation.  Over  the 
past  years  the  concept  of  information-based  warfare  has  been  gaining  in  importance  in  military 
organisations.  The  objective  of  information-based  warfare  is  to  achieve  a  decisive  military  advantage  by 
managing  and  using  data  in  all  of  its  forms.  The  following  research  findings  arise  from  the  implementation 
of  knowledge  management  concepts,  processes  and  systems  in  civil  organisations. 

•  Structured  and  organised  administration  of  all  kinds  of  information  and  their  logical  relations 
supported  by  modem  information  technology; 

•  Additional  information  (“information  about  information”)  about  the  information  producing 
organisation  and  process; 

•  Immediate  access  to  knowledge  inside  and  outside  an  organisation  (searching,  collecting  and 
navigating); 

•  “Comprehensive  Information  Area”  merging  training,  development  and  management; 

•  Simple  and  fast  integration  of  new  information  domains  via  appropriate  application  interfaces; 

•  “Experience  Management”  by  implementing  a  lessons  learned  process,  and  evaluating  experiential 
information  with  inductive  methods; 

•  “Information  Processing”  (Aggregation,  Filtering,  Mining,  Farming,  Statistic)  via  analytical  methods 
to  support  the  decision  making  process  based  on  user  requirements. 

The  scope  of  these  basic  functional  and  conceptual  requirements  can  instantaneously  be  transferred  to  the 
M&S  community.  Therefore  the  justified  claim  for  data  engineering  support  in  the  analytical  process 
should  be  broadened  to  an  all-embracing  information  management  concept. 
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The  Integrated  Army  Modelling  and  Simulation  Network  Project  is  the  first  step  towards  a  standardised 
information  management  in  the  M&S  community. 


3  INTEGRATED  ARMY  MODELLING  AND  SIMULATION  DATA 
NETWORK 

In  2000  the  M&S  Branch  of  the  GE  Army  Office  started  the  project  “Integrated  Army  Modelling  and 
Simulation  Data  Network”.  The  still  ongoing  activity  was  motivated  through  the  omnipresent  demand  for 
interoperability  and  the  time-consuming  and  cost-intensive  process  of  creating  data  sets  for  OR  Systems. 
The  main  effort  is  the  handling  of  structured  data  in  a  M&S  system  of  interoperable  systems. 

One  major  part  of  the  project  was  to  proof  the  concepts  with  prototypic  software  and  experiments.  The 
objective  was  to  use  approved  architectural  principles,  e.g.  the  ISO  IRDS  standard,  and  realise  them  with 
customised  Open  Source  products.  The  technical  implementation  is  based  on  the  use  of  the  eXtendend 
Markup  Language  (XML)  and  Python.  XML  is  developed  to  structure,  store  and  send  information.  The 
language  is  focus  on  the  description  of  data.  Python  is  a  portable,  interpreted,  object-oriented 
programming  language.  A  huge  variety  of  usable  Open  Source  Projects  were  issued  by  the  Python 
Community. 

3.1  Phase  1:  Feasibility  Studies 

Phase  1  was  a  set  of  mostly  independent  feasibility  studies  initiated  through  the  C4I  and  M&S  community. 
Phase  1  included 

•  a  conceptual  approach  for  a  national  data  management  process, 

•  a  proposed  architecture  outline  of  an  IT-System  supporting  the  data  management  process, 

•  the  usability  of  data  management  for  M&S  systems, 

•  the  assessment  of  the  significance  of  the  NATO  C3  Data  Model  as  a  standardised  and  flexible  data 
model  for  the  domain  of  Modelling  and  Simulation, 

•  the  prototypical  development  of  a  configurable  interface  technique  for  data  exchange  of 
heterogeneous  systems  on  the  basis  of  a  common  data  language. 

3.2  Phase  2:  Integrated  Army  Modelling  and  Simulation  Data  Network 

Summarising  the  results  of  the  feasibility  studies  the  objectives  of  Phase  2  were 

•  to  create  and  document  a  standardised  data  language  on  the  basis  of  NATO’s  Land  Command  and 
Control  Information  Exchange  Data  Model  (C2IEDM), 

•  to  formulate  an  interoperability  concept  of  simulation  systems  on  the  basis  of  a  common  language, 

•  to  provide  simulation-specific  information  on  the  basis  of  the  common  language, 

•  to  draft  a  conceptual  and  technical  framework  for  an  Integrated  Army  Modelling  and  Simulation  Data 
Network, 

•  to  prove  the  concepts  through  technical  experiments  by  using  prototypic  software. 

This  phase  was  mainly  carried  out  by  civil  contractors  under  the  lead  of  the  IABG,  which  were  already 
involved  in  national  interoperability  and  data  management  studies. 
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3.3  Phase  3:  Proof  of  Concept  and  Evolution 

The  main  part  of  Phase  3  is  the  proof  of  concept.  The  M&S  Branch,  GE  Army  Office  is  conducting  an 
operational  test  to  define  the  technical,  organisational  and  functional  requirements  of  an  Integrated  Army 
Modelling  and  Simulation  Data  Network. 

In  parallel  an  evolutionary  development  is  being  pushed  towards  the  vision  of  a  modular  Modelling  and 
Simulation  Network.  The  Agenda  of  Phase  3  includes 

•  the  integration  of  Common  Application  Services  using  the  developed  concepts, 

•  the  extension  of  the  standardised  data  language  (information  concepts  “Command  and  Control”, 
“Finance”), 

•  the  standardised  representation  of  terrain  and  environmental  data, 

•  the  standardised  representation  of  methods,  algorithms,  their  parameters  and  relations. 

4  ARMY  CORPORATED  MODELLING  AND  SIMULATION  DATA  MODEL 
4.1  Data  Modelling 

M&S  concepts  postulate  interoperability,  modular  architecture,  reuse  of  components  and  dynamic  linking. 
These  conceptual  demands  have  not  been  translated  into  action  yet.  To  build  federations  of  OR  systems 
the  required  levels  of  interoperability  standards  have  to  be  officially  enforced.  Level  1  (Technical 
Information  Exchange)  is  covered  through  a  variety  of  activities  like  the  HLA  Runtime  Infrastructure, 
DIS,  CORBA  and  XML.  Level  2  and  Level  3  interoperability  (syntactical  and  semantic  information 
exchange)  requires  a  standardised  information  exchange  language.  The  NATO  Policy  for  C3 
Interoperability  [NC3B  Sub-Committee  AC/322  SC/2-WP/72  (Revised)  Version  4.3]  calls  for  “seamless 
sharing  of  data  that  involves  the  automated  sharing  of  data  amongst  systems  based  on  a  common  exchange 
model.” 

Today  in  the  M&S  community  the  definition  of  information  is  an  “art  work”  of  every  individual 
programmer.  A  common  sense  information  concept  of  the  M&S  domain  is  not  existent.  Extensive  efforts 
have  to  be  undertaken  to  reach  very  limited  semantic  interoperability  between  existing  legacy  systems. 
Due  to  this  fact  the  operational  usefulness  of  linking  legacy  systems  might  be  called  into  question. 
However  to  build  future  federations  of  network  oriented  systems  the  information  domain  of  M&S  has  to 
be  organised  by  an  ontological  design  process.  This  process  separates  the  meaning  of  information  from  the 
information  content.  Objects,  relationships,  attributes  and  processes  are  organised  and  documented. 

Using  standardised  data  modelling  techniques  and  data  model  schemes  NATO  designates  the  ontological 
design  process  as  Data  Management  and  the  ontology  itself  as  Data  Model. 

The  ATCCIS  Project  has  already  started  to  define  the  Land  Command  and  Control  Information  Exchange 
Data  Model  (LC2IEDM)  to  serve  as  the  common  interface  specification  for  the  exchange  of  essential 
battlespace  information.  The  LC2IEDM  extended  with  a  national  Maritime  Core  Data  Model  was  the 
baseline  of  the  M&S  data  management  activities.  The  results  of  the  analysis  of  a  wide  range  of  simulation 
systems  were  customising  or  complementing  the  LC2IEDM.  The  external  data  representation  of  various 
constructive  simulations,  high  resolution  vulnerability  models,  three-dimensional  constructive  simulations 
and  training  simulators  were  harmonised  and  documented.  The  results  of  the  initial  data  management 
activities  were  available  in  December  2002  and  issued  as  Army  Modelling  and  Simulation  Corporated 
Data  Model  ( AMSCorpDM)  Vs.  1.0.  Examples  of  appended  information  concepts  are  the  “3 -dimensional 
Location  View”,  “Ballistic  View”,  “Lethality  and  Vulnerability  View”,  “Supplemented  Person  View” 
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(medical  description  of  the  human  body). 

The  AMSCorpDM  can  be  used  as 

•  source  for  standardised  data  elements  inside  an  OR  system, 

•  a  template  for  a  standardised  external  data  representation  of  simulation  systems  to  support  the 
integration  in  a  M&S  network  or  system  of  systems, 

•  an  interface  specification  to  get  legacy  systems  inside  the  network  or  system  of  systems. 

Objective  is  to  get  the  standardised  data  elements  as  deep  as  possible  inside  a  system. 

Proceeding  in  accordance  with  the  information  exchange  requirements  and  data  definitions  of  the 
incorporated  simulation  systems  the  “common  sense”  modelling  process  defines  information  concepts  on 
the  basis  of  approved  field-manuals,  encyclopaedias,  glossaries  and  ontologies.  As  a  result  of  the  semantic 
enrichment  the  system  oriented  mutual  interface  specification  language  migrated  to  a  universal  Modelling 
and  Simulation  ontology. 


[Field  Manuals 
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Figure  2:  “Common  Sense”  Data  Management 

Adapted  from  the  IDEF1X  format  an  ontology  schema  was  developed  and  designated  as  Data 
Management  Reference  Data  Model.  IDEF1X  supports  the  semantic  constructs  necessary  in  developing  a 
conceptual  schema  for  a  relational  database.  A  conceptual  schema  is  a  single  integrated  definition  of  the 
domain  data  that  is  unbiased  toward  any  single  application  and  independent  of  its  access  and  physical 
storage. 

4.2  Data  Management  Information  Resource  Dictionary 

The  responsiveness  and  flexibility  of  the  data  management  process  is  crucial  for  its  acceptance.  For  this 
purpose  a  flexible  and  adjustable  architecture  of  an  information  management  system  was  developed 

•  to  enable  the  integration  in  the  system  development  process, 
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•  to  provide  efficient  documentation  of  existing  standards  to  be  used  by  system  developers, 

•  to  support  flexible  processes  responding  to  information  requirements  in  time  to  prevent  delays. 

The  system  architecture  is  based  on  the  ISO  Information  Resource  Dictionary  System  (IRDS)  Framework. 


IRD  Definition  Schema 
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Figure  3:  Data  Management  -  IRDS 


4.2.1  Layer  3  (IRD  Definition  Schema  Level)  -  NATO  C3  Data  Model 

The  NC3DM  as  a  generic  data  model  defines  the  structure  of  the  dictionary.  This  data  model  is  used  as  a 
container  and  will  be  physically  implemented  in  a  database  management  system. 

By  direction  of  the  NATO  Information  Systems  working  group  the  NATO  C3  Data  Model  was  created  as 
a  generic  data  structure  to  store  an  application  data  model  or  schema  and  the  related  application  data  in  it. 
So  changes  to  the  data  model  are  made  via  configuration  in  the  NC3DM  and  not  via  software  update. 

4.2.2  Layer  2  (IRD  Definition  Level):  Data  Management  Reference  Data  Model 

The  Information  Resource  Dictionary  Schema  of  the  Data  Management  Process  {Data  Management 
Reference  Data  Model )  is  defining  the  data  management  information  stored  in  the  Information  Resource 
Dictionary. 

4.2.3  Layer  1  (IRD  Level):  Data  Management  Data 

At  the  IRD  level  the  actual  information  of  the  data  management  process  is  stored  as 

•  application  schemes  of  incorporated  systems, 

•  standardised  data  elements 

•  AMSCorpDM 

•  mediation  rules  between  AMSCorpDM  and  application  schemes. 

A  web  based  Data  Management  Information  System  (DaMIS)  can  be  automatically  created  with  the 
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DaMIRD  to  support  system  developers  and  data  managers  with  all  information  within  the  Information 
Repository. 


5  M&S  DATA  DOCUMENT  ARCHIVE 

The  results  of  Operations  Research  methods  eminently  depends  on  the  accuracy,  integrity  and  plausibility 
of  the  available  data.  The  analytical  process  and  its  embedded  OR  systems  requires  specific  problem 
oriented  data.  Today  at  the  beginning  of  an  analytical  process  data  collection  starts  as  an  individual  sub¬ 
process.  Information  from  different  data  sources  is  manually  processed  into  the  required  system  specific 
format.  Even  for  common  data  domains  like  force  structure,  weapon  system  data,  vulnerability  and 
weapon  effectiveness  data  a  comprehensive  source  is  not  available. 

In  compliance  with  information  management  principles  and  data  warehouse  concepts  a  conceptual 
framework  for  a  M&S  data  warehouse  was  defined: 

•  Data  must  be  available  in  time.  Situation  oriented  data  collection  is  time-consuming.  The  M&S  Data 
Warehouse  has  to  support  a  routine  data  collection,  update  and  amendment  process.  The  objective  is 
to  anticipate  possible  information  requirements  to  minimise  the  expense  of  individual  data  collection 
processes. 

•  Data  must  be  communicable.  The  meaning  of  the  data  content  has  to  be  clearly  defined  for  the  use  in 
analytical  processes  and  OR  methods.  The  available  AMSCoipDM  was  consequently  implemented  as 
application  schema  for  the  M&S  Data  Warehouse. 

•  Data  must  be  relevant  to  the  problem.  OR  methods  require  specific  data  views.  These  data  views  will 
be  kept  together.  After  the  mediation  into  a  standardised  data  view  based  on  the  schema  of  the 
AMSCoipDM  the  data  view  is  stored  as  a  document  in  the  M&S  Data  Warehouse.  The  M&S  Data 
Warehouse  is  an  archive  of  a  huge  number  of  documents.  The  term  M&S  Data  Document  Archive  is 
more  descriptive 
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Figure  4:  Dual  Use  -  IRDS 


•  Data  must  be  retrievable.  In  the  sense  of  information  management  to  browse,  to  categorise  and  to 
analyse  data  documents  meta  data  have  to  be  added  to  the  original  data  document  before  storing  in  the 
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M&S  Data  Document  Archive. 

•  Data  must  be  adjustable.  The  use  of  the  AMSCorpDM  as  IRD  Schema  on  the  IRD  Definition  level 
allows  to  adjust  the  M&S  Data  Document  Archive  schema  via  the  specified  data  management  process. 

The  concept  of  the  M&S  Data  Document  Archive  leads  to  the  decision  to  unify  the  functionality  of  the 
Data  Management  Information  Resource  Dictionary  and  the  M&S  Data  Document  Archive.  Technical 
studies  proved  the  possibility  to  store  two  ore  more  IRD  Schemes  in  the  NC3DM.  Beside  the  Data 
Management  Reference  Data  Model  the  Army  Modelling  and  Simulation  Corporate  Data  Model  was 
embedded  in  the  IRD  Definition  level  defining  the  common  user  data  at  the  IRD  Level. 

An  XML  workbench  allows  the  enrichment  of  user  data  with  meta  data.  The  term  “meta  data”  is  not  used 
in  the  sense  of  the  ISO  IRDS  Framework  but  data  which  describes  data.  Therefore  a  Meta  Data  Schema 
was  defined.  It  includes  semantic  definitions  for  the  data  originator,  status  of  verification,  validation  and 
accreditation,  context  and  topic,  reliability  and  accuracy.  Navigation  and  searching  in  the  XML  document 
archive  will  be  ensured  via  predefined  Frequently  Asked  Questions  provided  by  the  Query  Workbench. 
All  data  manipulation,  data  aggregation  and  statistical  evaluation  functions  can  be  realised  as  a  process 
oriented  XML  editor. 


Figure  5:  M&S  Document  Archive 


6  SYSTEM  INTEGRATION  PROCESS 

The  concept  of  an  XML-based  framework  for  a  M&S  system  of  systems  requires  a  minimum  of  pre¬ 
conditions.  Every  system  which  uses  XML  for  data  export  and  import  can  be  integrated  as  federate.  The 
optimum  would  be  if  federates  already  incoiporated  the  standardised  semantic  and  syntax  of  the 
AMSCoipDM. 

The  present  legacy  systems  are  not  designed  to  communicate  in  a  standardised  environment  or  do  not 
possess  documented  and  standardised  Application  Programming  Interfaces.  Therefore  the  individual  data 
representation  of  an  application  has  to  be  transformed  into  an  XML  structured  data  document  via  a  System 
-  XML  Proxy.  For  the  mediation  process  the  individual  logic  data  model  of  this  system  specific  XML  data 
document  has  to  be  documented  in  a  template  and  imported  as  application  schema  into  the  Data 
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Management  Information  Resource  Dictionary.  The  structure  of  the  documentation  template  is  based  on 
the  IDEF1X  notation. 

To  get  a  standardised  data  document  the  individual  application  schema  of  the  system  data  document  is 
mapped  on  the  AMSCorpDM.  The  mapping  rules  are  documented  in  a  mediation  template  and  in  the 
DaMIRD.  This  Mediation  Template  will  initialise  the  Data  Mediation  Function  (DMF).  The  DMF  is  a 
configurable  interface  software  which  supports  the  data  migration  from  a  system  data  document  into 
standardised  data  document.  The  software  can  be  integrated  into  systems  to  provide  a  standardised  data 
import  and  export  functionality  based  on  XMF  and  the  AMSCorpDM. 


Figure  6:  System  Integration 


The  data  exchange  from  system  A  to  system  B  can  technically  be  realised  as  crosswalk  from  the  individual 
data  document  (A),  mediated  to  the  standardised  data  document  (A)  in  the  AMSCorpDM  language. 
Overlapping  information  concepts  of  standardised  system  data  document  (A)  with  standardised  system 
data  document  (B)  can  be  transformed  directly,  gaps  and  semantic  differences  have  to  be  bridged  by 
Application  Gateways. 
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Manual 

XLS-Template  (Mediation) 

Meta  Data  Schema  (Data  Management 
Reference  Schema) 

AMSCorpDM 

Manual 

XLS-Template  (Data  Management) 

NC3DM 

Table  1:  Document  Overview 
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The  same  methodology  can  be  used  to  realise  the  information  exchange  between  OR  systems,  C4I  systems 
and  other  IT  systems. 


Figure  7:  Data  Exchange 


6.1  Multi-Role  Common  Platform 

The  functionality  of  the  unified  M&S  Data  Document  Archive  /  Data  Management  IRDS  is  tailored  to 
different  roles  depending  on  the  supported  processes  and  the  required  information  of  an  organisation.  The 
Multi-Role  Common  Platform  supports  data  management,  data  provision,  data  processing  and  data 
exchange.  The  process  tailored  satellites  can  be  linked  into  an  Army  M&S  Integrated  Data  network  which 
forms  an  eminent  component  of  a  future  M&S  system  of  systems  or  M&S  network. 


7  CONCLUSION 

Starting  from  national  and  international  concepts  and  standards  an  operational  and  technical  architecture 
of  an  Information  Management  System  was  developed.  Experiments  proved  the  feasibility  and  practicality 
for  various  simulation  systems.  However  it  is  one  of  the  preliminary  steps  towards  a  M&S  system  of 
systems.  One  major  future  task  is  to  enforce  the  implementation  of  the  approved  standardisation  activities. 

In  December  2004  the  GE  Army  Office  will  issue  a  final  project  report  and  will  come  forward  with  a 
proposal  for  the  further  way  ahead. 
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SUMMARY 

The  Royal  Netherlands  Army  (RNLA)  is  currently  developing  the  C2  Workstation  (C2WS),  which  is  a 
configurable,  distributed  information  system  that  provides  generic  functionality  to  support  the  Command 
and  Control  process.  One  of  the  main  tasks  of  the  C2WS  is  to  support  the  users  in  building  and 
maintaining  a  Common  Operational  Picture  (COP)  that  provides  adequate  situational  awareness.  TNO- 
FEL  has  performed  experimental  studies  on  the  C2WS  to  investigate  the  issues  related  to  interoperability 
between  C2  systems  and  simulators.  The  aim  is  twofold  :  support  the  staff  training  process  by  using  the 
C2WS  as  an  interface  between  trainees  and  simulation  tool  (‘train  as  you  fight)  and  investigate  the 
options  for  operational  C2  decision  support  tools  based  on  simulators. 

The  RLNA  performs  staff  training  through  Computer  Assisted  eXercises  (CAX)  with  the  ‘KIBOWF 
constructive  simulator.  Currently  manned  Lower-Control  cells  provide  the  interface  between  the 
simulation  and  the  trainees.  The  vision  for  the  future  is  to  develop  more  automated  interfaces  between  the 
simulator  and  the  C2  systems.  The  simulation  will  provide  stimuli  to  the  C2WS  (e.g.  unit  detection  or 
displacement)  and  thus  interact  with  the  trainees  through  the  operational  C2  systems.  Instructors  can  now 
also  better  assess  the  user's  performance  with  these  C2  systems.  Interoperability  with  Decision  Support 
Systems  (DSS)  concentrates  on  Course  of  Action  (CO A)  analysis  and  mission  planning.  The  mission  plan 
is  defined  in  the  C2WS  and  automatically  transferred  to  the  DSS.  The  DSS  analyses  this  input  through 
simulation  and  predicted  results  (e.g.  rendezvous  times)  are  routed  back  into  the  C2WS  as  a  new  planning 
overlay  available  for  evaluation  by  the  C2  operator. 

The  architectural  approach  to  our  interoperability  need  is  to  provide  a  software  gateway  between  the 
C2WS  communication  network  (based  on  XML  messaging)  and  the  High  Level  Architecture  (HLA) 
standard.  The  link  to  HLA  provides  the  possibility  to  connect  many  modern  simulation  components  to  the 
C2WS  architecture.  The  HLA  development  process  that  was  followed  provides  a  generic  approach  to 
simulation  interoperability  for  the  C2WS.  This  process  concentrates  on  defining  a  datamodel  that  matches 
the  requirements  and  features  of  both  the  C2  system  and  the  available  simulation  assets. 

This  paper  presents  an  overview  of  the  possible  use  of  interoperability  between  C2  systems  and  simulation 
systems,  an  overview  of  the  architecture,  the  development  of  the  demonstrator  and  our  results  to  date. 


Paper  presented  at  the  MSG-022/SY-003  Conference  on  “C3I  and  M&S  Interoperability  ”, 
held  in  Antalya,  Turkey.  9-10  October  2003,  arid  published  in  RTO-MP-MSG-022. 
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1.  INTRODUCTION 

This  paper  addresses  the  approach  used  by  TNO-FEL  to  develop  and  demonstrate  concepts  for 
interoperability  between  C2  systems  and  Simulations.  Simulation  interoperability  for  C2  systems  enables 
applications  in  training  of  military  users,  operational  support,  procurement  and  assessment  and  evaluation 
of  C2  systems.  The  presented  project  is  aimed  specifically  at  the  Command  &  Control  Workstation 
(C2WS),  a  new  C2  information  system  for  the  Royal  Netherlands  Army  (RNLA),  which  is  under 
development.  The  requirements  for  the  design  of  the  C2-Simulation  interoperability  architecture  are: 
flexibility,  scalability,  robustness  and  compliance  to  international  standards. 

As  a  first  demonstrator  of  interoperability  between  C2  systems  and  simulations,  the  coupling  of  C2WS 
and  the  KIBOWI  wargame,  an  HLA  (High  Level  Architecture)  based  Simulation  system,  was  chosen.  The 
demonstrator  concentrates  on  providing  improved  Situational  Awareness  (SA)  for  trainees  by  means  of  the 
C2WS. 

The  next  section  of  the  paper  addresses  the  need  for  interoperability  and  the  general  concept  of  coupling 
C2  systems  to  Simulations.  Sections  3,  4  and  5  explain  the  background  for  the  C2WS,  KIBOWI  and  HLA. 
The  following  sections  discuss  the  system  architecture,  implementation  issues  and  some  results  and 
conclusions  of  this  project. 


2.  LINKING  C2  SYSTEMS  TO  SIMULATION  MODELS 

Linking  C2  systems  to  Simulation  systems  has  many  potential  applications.  Simulation  systems  can 
stimulate  the  C2  system  by  providing  data  that  simulates  the  'real-world'.  This  information  will  appear  to 
have  been  received  from  peer  C2  systems.  In  this  way  a  simulated  COP  (Common  Operational  Picture)  is 
created  that  is  based  on  a  simulation  scenario.  Applications  of  this  technique  are:  assessment  of  C2 
systems  (performance,  user  interface  etc.),  assessment  of  C2  operator  capabilities  or  training  of  C2 
operators.  The  simulation  can  provide  the  C2  operator  with  operational  decision  support  by  executing 
'what-if  scenarios.  These  scenario's  can  support  the  operator  in  his  decision  making  process  (e.g.  mission 
planning  or  assessment  of  alternative  COA's).  New  or  experimental  parts  for  an  existing  C2  system  can  be 
evaluated  before  purchase  or  even  before  full  development  of  the  component  by  replacing  an  existing 
component  of  the  C2  system  with  an  embedded  or  external  simulation.  Simulated  systems  can  be 
'initialised'  from  the  existing  COP  in  the  C2  system  and  a  simulation  run  can  be  started  based  on  this 
information.  The  advantage  of  using  simulations  as  a  tool  for  stimulation  of  C2  systems,  as  opposed  to 
'role  players',  is  that  the  simulation  has  a  consistent,  controlled  and  reproducible  behaviour,  which  allows 
objective  assessment  of  system  and/or  operator  performance.  TNO-FEL  has  recognised  an  opportunity  to 
support  the  C2WS  assessment  activities  and  the  current  C2  staff  training  process  by  ongoing  experimental 
studies  on  coupling  of  our  simulation  tools  with  C2  systems.  The  aim  of  the  research  is  to  develop  a 
flexible  and  future-proof  approach  to  the  C2- Simulation  interoperability  problem.  First  we  need  to  clarify 
what  we  really  mean  by  'interoperability'.  Interoperability  is  the  degree  to  which  entities  are  able  to  co¬ 
operate  in  achieving  a  common  goal.  There  are  many  interpretations  of  the  concept  of  interoperability 
between  computer  systems.  It  varies  from  having  a  network  connection  and  being  able  to  transfer  files 
(e.g.  email)  to  using  exactly  the  same  applications  at  all  systems  and  completely  sharing  the  information 
they  process.  A  commonly  used  form  of  interoperability  is  'information  interoperability',  because  it  offers 
optimal  connectivity  between  systems,  while  preserving  maximum  independence.  Information 
interoperability  is  defined  as  the  ability  of  systems  to  automatically  exchange  and  interpret  information 
that  is  common  to  those  systems  [1]. 

In  this  paper  we  focus  on  information  interoperability  that  is  achieved  by  the  automated  exchange  and 
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interpretation  of  structured  information  between  systems.  With  minimum  user  intervention,  C2  systems 
and  Simulation  systems  must  be  able  to  automatically  interchange  certain  information  and  utilise  that  for 
further  processing.  This  means  that  the  information  must  be  structured,  because  this  enables  functionality 
such  as  distribution  by  subscription  on  certain  topics,  presentation  of  information  and  filtering  by  specific 
selection  criteria.  The  emphasis  here  lies  on  the  exchange  of  information  (rather  than  'free  format' 
databits),  preserving  its  meaning,  integrity  and  context.  Structured  information  is  described  formally  by  a 
'Datamodel'.  The  datamodel  thus  represents  the  foundation  for  information  interoperability.  In  the  most 
common  case  where  many  systems  have  to  exchange  information,  standardisation  of  a  common  ‘interface’ 
is  a  key  factor  to  achieve  information  interoperability.  Otherwise,  dedicated  interfaces  are  needed  between 
every  pair  of  interconnected  systems,  leading  to  an  exponential  growth  of  the  number  of  interfaces 
required  [Figure  1],[8].  Preferably  the  exchange  should  not  depend  on  proprietary  products,  such  as 
database  management  systems  and  communication  systems. 


Figure  1  C2  and  Simulation  Interoperability  (dedicated  interface) 

The  key  notion  for  information  interoperability  is  standardisation.  By  having  common  agreements  on 
which  information  is  exchanged,  in  what  format,  and  under  what  conditions,  it  becomes  easier  to  allow 
systems  of  different  types  to  interoperate  [Figure  2]. 


Figure  2  C2  and  Simulation  Interoperability  (standard  interface) 


3.  COMMAND  &  CONTROL  WORKSTATION  (C2WS) 

The  C2WS  [Figure  3]  is  a  configurable  application  platform  and  information  system  that  provides  generic 
functionality  to  support  the  Command  and  Control  process.  The  C2WS  supports  the  users  in  building  and 
maintaining  a  COP  that  provides  adequate  Situational  Awareness.  The  C2WS  is  being  developed  at  the 
RNLA  C2  Support  Centre,  with  co-operation  of  TNO-FEL.  The  system  architecture  of  the  C2WS 
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comprises  of  three  layers:  presentation  services,  business  services,  and  data  services. 

The  presentation  services  layer  is  responsible  for  gathering  information  from  the  user  and  presenting 
information  to  the  user  using  the  services  of  the  business  services  layer. 

The  business  services  layer  is  responsible  for  end-to-end  business  transactions  such  as  maintaining  roles, 
contexts  and  business  objects  and  the  logic  that  applies  within  these  concepts. 

The  data  services  layer  is  responsible  for  storage,  retrieval,  maintenance  and  integrity  of  data.  The  data 
services  layer  is  also  in  charge  of  publishing  as  well  as  subscribing  and  listening  to  data  on  the  C2 
network. 

The  information  exchange  in  the  C2WS  environment  is  implemented  through  a  middleware  layer  named 
‘C3I  Framework’.  The  middleware  follows  the  RNLA  C3I  Architecture  (C3IA)  Information  Model 
(C3IA-IM)  for  C2  applications  within  the  RNLA  [2].  The  C3I  Framework  uses  commercial  of  the  shelf 
publish/subscribe  services  (Tibco  Rendezvous)  and  a  tailored  information  exchange  language  based  on 
XML  messaging.  The  C2WS  has  conversion  modules  for  RNLA  legacy  systems  such  as  the  Integrated 
Staff  Information  System  'ISIS'  and  for  the  future  Battlefield  Management  System  'BMS'. 


Figure  3  C2WS  GUI  (RNLA  prototype) 

At  the  time  of  writing,  the  C2WS  supports  GIS  functionality  for  placing  units  and  lines/areas  on  the  map. 
The  network  functionality  is  partly  implemented,  for  example  updates  of  the  COP  for  a  certain  'context' 
can  be  exchanged  between  different  C2WSs.  Flowever  a  means  for  a  new  C2WS  to  hook  into  the  network 
and  receive  the  full  current  COP  has  not  yet  been  implemented. 


4.  KIBOWI 

KIBOWI  is  a  detailed  constructive  combat  simulation  model  that  takes  into  account  manoeuvre,  fire 
support,  combat  engineering,  air  defence,  air  support,  combat  service  support  operations  and  amphibious 
operations.  The  model  is  capable  of  simulating  ground  operations  at  battalion,  brigade  and  division  levels. 
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KIBOWI  can  represent  entities  on  a  platform  (e.g.  vehicle)  and  aggregate  (e.g.  platoon,  company)  level. 
KIBOWI  is  normally  used  by  the  RNLA  as  an  exercise  driver  for  Command  Post  Exercises  (CPX).  Some 
other  users  are  Belgian  brigades  and  the  Bulgarian  army.  Primary  training  audiences  are  typically  staffs  at 
battalion,  brigade,  and  division  level. 

In  the  C2WS-KIBOWI  federation  KIBOWI  drives  the  demonstration  scenario  by  providing  an  operational 
context  for  the  mission.  The  operational  context  simulated  by  KIBOWI  consists  of  formations  of  own  and 
hostile  ground  forces.  These  units  provide  a  dynamic  and  representative  environment  for  the  C2WS 
operations.  During  a  scenario  run,  each  KIBOWI  unit  executes  a  predefined  list  of  orders.  This  eliminates 
the  need  for  user  interaction  during  execution  and  ensures  repeatability  of  the  scenario. 


Figure  4  KIBOWI  GUI 

KIBOWI  simulates  both  aggregated  and  platform  level  entities  in  the  scenario.  Since  KIBOWI  is  not 
capable  of  aggregating  and  de-aggregating  units  dynamically,  care  had  to  be  taken  during  scenario  design 
that  no  interactions  would  occur  between  KIBOWI  aggregate  units. 

An  HLA  compliant  version  of  KIBOWI  was  developed  in  the  context  of  the  NATO  DiMuNDS  2000 
project.  Because  no  RTI  implementation  was  available  for  the  platform  that  the  KIBOWI  software  runs  on 
(i.e.  Open  VMS  on  Digital  AlphaStation),  KIBOWI  uses  a  gateway  component  to  link  to  the  HLA. 

The  C2WS-KIBOWI  federation  adopted  the  DiMuNDS  2000  datamodel  with  only  a  limited  number  of 
modifications.  Therefore,  the  KIBOWI  HLA  gateway  could  be  adapted  easily  to  the  new  federation 
(mainly  the  mapping  functions  were  affected).  No  changes  were  required  in  the  code  of  KIBOWI  itself. 


5.  HIGH  LEVEL  ARCHITECTURE  (HLA) 

The  High  Level  Architecture  (HLA)  is  an  architecture  for  reuse  and  interoperation  of  simulations  [3],  [4], 
[5],  [Figure  5].  The  HLA  is  based  on  the  premise  that  no  single  simulation  can  satisfy  the  requirements  of 
all  uses  and  users.  An  individual  simulation  or  set  of  simulations  developed  for  one  purpose  can  be  applied 
to  another  application  under  the  HLA  concept  of  the  Federation:  a  composable  set  of  interacting 
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simulations. 


Figure  5  UFA  Federation 

The  intent  of  HLA  is  to  provide  a  structure  that  will  support  reuse  of  capabilities  available  in  different 
simulations,  ultimately  reducing  the  cost  and  time  required  to  create  a  synthetic  environment  for  a  new 
purpose  and  providing  developers  the  option  of  different  implementations  within  the  framework  of  the 
HLA.  The  baseline  definition  of  the  HLA  includes  the  HLA  Rules,  the  HLA  Interface  Specification 
(IFSpec),  and  the  HLA  Object  Model  Template  (OMT).  The  HLA  interface  specification  defines  the 
services  that  HLA  provides  to  the  application.  These  services  include  Object  Management 
(publish/subscribe)  and  Time  Management  (i.e.  synchronisation  between  distributed  applications).  The 
Federation  Object  Model  (FOM)  is  the  datamodel  of  the  HLA  Federation.  The  OMT  is  the  standard 
datamodel  format  that  is  used  in  HLA  documentation.  The  HLA  specification  was  adopted  by  the  US 
Defense  Modelling  and  Simulation  Office  (DMSO),  by  NATO  and  it  has  now  been  accepted  as  IEEE 
Standard  1516  for  simulation  interoperability.  Development  of  a  generic  coupling  between  C2  systems 
and  HLA  thus  provides  the  possibility  to  connect  modem  simulation  components  to  the  C2  environment. 

One  of  the  main  components  of  HLA  is  the  Run-Time  Infrastructure  (RTI).  The  RTI  implements  the  HLA 
IFSpec  and  allows  the  user  to  invoke  the  RTI  services  to  support  run-time  interactions  among  Federates 
and  to  respond  to  requests  from  the  RTI.  This  interface  is  implementation  independent  and  is  independent 
of  the  specific  object  models  and  data  exchange  requirements  of  any  Federation.  At  TNO-FEL  we 
developed  an  HLA  based  middleware  layer,  called  the  Runtime  Communication  Infrastructure  (RCI)  [6] 
which  supports  HLA.  The  RCI  shields  the  developer  from  many  intricate  details  concerning  the  usage  of 
the  HLA-RTI  when  developing  either  a  Component  or  a  Federate.  The  RCI  includes  a  C++  code-generator 
to  translate  the  required  HLA-OMT  descriptions  into  easily  accessible  object-oriented  classes. 


6.  BRIDGING  THE  GAP 

Previous  attempts  to  couple  C2  systems  with  simulations  were  often  ad-hoc  and  resulted  in  tailor-made 
connections  for  every  specific  combination  of  C2  systems  and  simulation  models  (See  also  references  in 
[8]).  A  new  connection  had  to  be  developed  for  each  new  system  that  needs  to  be  included.  This  approach 
means  a  lot  of  work  for  both  the  C2  system  and  the  simulation  models,  [see  Figure  1].  A  more  flexible 
approach  is  the  use  of  an  intermediate  layer  as  show  in  [Figure  2]. 

Once  a  system  or  simulation  has  a  (tailor  made)  adapter  for  the  intermediate  layer,  the  system  can  be 
connected  to  other  systems  or  simulations  without  any  additional  work  on  the  other  players. 
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The  approach  that  was  followed  to  achieve  C2WS-Simulation  interoperability  resembles  the  'intermediate 
layer'  solution,  however  with  an  important  difference:  both  the  C2WS  systems  and  the  Simulation  systems 
already  support  interoperability  within  their  own  domain. 

The  C2WS  system  uses  the  ‘C3I  Framework’  middleware,  which  is  based  on  Tibco/Rendezvous.  The 
simulation  systems  use  the  FILA  interoperability  standard.  We  have  developed  a  'Tibco-FILA  gateway'  to 
connect  TIB/RV  on  one  side  to  FILA  on  the  other  side  (see  Figure  6). 

In  addition  to  interoperability  at  the  technical  level  (protocols,  networks  etc),  we  also  need  to  develop  the 
information  interoperability  for  the  gateway  which  aligns  the  Datamodels  and  provides  a  two-way 
mapping  for  all  relevant  attributes.  HLA  federates  define  their  data  exchange  via  a  Federation  Object 
Model  (FOM).  The  FOM  has  to  be  agreed  upon  between  the  systems  that  need  to  be  connected.  For  the 
C2-Simulation  system  a  C2WS-KIBOWI  Federation  has  been  designed  together  with  an  initial  FOM 
based  upon  the  FOM  used  previously  in  the  NATO  DiMuNDS  2000  demonstration  [7], 


Figure  6  C2-Simulation  Datamodel  Interoperability 

This  FOM  describes  four  generic  objects,  which  are  : 

•  Weather, 

•  Stationary, 

•  StationaryMultiLocation  and 

•  Mobile 

The  information  that  is  exchanged  via  the  FOM  consists  amongst  other  things  of  the  position  of  the  object 
and  depending  on  the  object  information,  for  example  status  and  speed.  Given  the  different  development 
history  of  the  C2WS  and  the  DiMuNDS  FOM  it  is  often  impossible  to  directly  map  the  information 
exchanged  between  C2  systems  onto  the  FOM. 

In  most  cases  it  is  necessary  to  combine  information  from  the  C2  system  in  order  to  get  it  mapped  onto  the 
FOM  and  vice  versa.  For  example,  the  following  fields  were  identified  for  a  unit  message  that  need 
adaptation  before  they  can  be  mapped  on  either  the  FOM  or  on  the  C2  information. 
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Table  1  Data  mapping  fields  (not  exhaustive) 


FOM 

C2WS 

ObjName 

Name 

PartyNumber 

Nationality 

Velocity 

SpeedQty 

Position 

Position 

Front 

BearingAngle 

A  name  in  the  FOM  needed  to  be  restricted  to  10  characters,  the  FOM  only  knows  of  four  different  parties 
while  the  C2WS  allows  many  more  different  nationalities,  and  the  location  of  a  unit  in  the  UTM  system  of 
the  C2WS  needed  to  be  translated  into  the  relative  map  co-ordinates  used  by  the  FOM.  Specific 
conversions  and  layout  issues  had  to  be  resolved  and  implemented  to  realise  any  coupling  between  the  two 
domains. 

The  C2WS-FILA  Gateway  was  developed  for  the  purpose  of  incoiporating  a  C2WS  in  the  Federation.  This 
Gateway  (see  Figure  7)  was  implemented  using  two  processes,  one  attached  to  the  RCI  (FILA  middleware) 
and  the  other  attached  to  C3I  Framework.  Both  sides  use  a  publish/subscribe  method  to  distribute  data  on 
their  respective  networks.  The  C3I  Framework  listens  to  messages  on  the  C2  network  and  places  an  image 
of  the  object/interaction  data  concerning  the  C2WS  entities  (to  which  a  subscription  was  issued  by  the 
Gateway)  in  shared  memory.  The  RCI  process  subsequently  reads  this  data  from  shared  memory  and  maps 
it  onto  the  FILA-FOM  via  the  RCI  middleware.  The  same  holds  for  communicating  data  from  the  FILA 
Federation  to  the  C2WS  world  where  the  C3I  Framework  publishes  and  updates  the  object/interaction  data 
received  from  the  Federates  in  the  simulation. 


C2WS  Gateway  Simulation 


‘GUI’  for  Staff  Training  Tool  Staff  Training  Tool 


Figure  7  C2WS  Federation  with  C2WS-HLA  Gateway 


The  Gateway  code  is  currently  'handcrafted'.  Development  of  a  Codegenerator  tool  that  translates  C2WS 
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object  structures  into  ‘OMT’  like  datastructures  would  simplify  matters.  Such  a  tool  would  effectively  turn 
the  C2WS-HLA  Gateway  into  an  OMT-to-OMT  mapping  process. 


7.  RESULTS 

The  prototype  demonstrator  for  the  C2WS-KIBOWI  federation  is  capable  of  generating  a  COP  image  on 
the  C2WS  based  on  data  received  from  KIBOWI  (‘oneway’  traffic).  The  gateway  handles  a  limited  set  of 
units  and  other  C2  items,  which  shall  be  extended  in  further  versions  of  the  demonstrator. 

Due  to  the  early  stage  of  the  development  of  the  C2WS,  some  cumbersome  precautions  have  to  be  taken 
when  demonstrating  the  simulation  functionality.  The  COP  updates  on  the  C2WS  are  incremental,  so  only 
changes  are  broadcast  to  other  C2  stations.  A  full  COP  transfer  for  when  a  new  C2WS  is  added  to  the 
network,  or  in  our  case,  for  simulation  purposes,  has  not  yet  been  implemented  in  the  current  version. 

Implementing  a  coupling  of  this  RNLA  C2  system  with  a  simulation  component  in  such  an  early  stage  of 
its  development  has  resulted  in  encouraging  insights  in  the  possible  additional  functionality  required  of  the 
C2WS  and  indeed  other  C2  systems. 


8.  CONCLUSIONS  AND  LURTHER  WORK 

The  demonstration  system  achieved  its  overall  objectives  and  so  far  received  positive  reactions  from  its 
audience.  Some  lessons  learned  to  date  from  the  project  are: 

•  Use  a  single  (authoritative)  source  for  common  data  like  terrain  maps  and  data,  co-ordinate 
conversion  algorithms,  equipment  and  weapon  parameters,  etc.; 

•  Test  and  Evaluation  of  C2WS  prototypes  in  a  simulated  environment  is  very  cost  effective; 

•  Operators  need  to  become  aware  that  C2WS  response  is  not  ‘real-time’; 

•  Operators  need  to  become  aware  that  C2WS  information  is  not  always  the  ‘truth’. 

•  Pursue  for  a  standardised  C2-Simulation  Datamodel,  represented  in  FOM  format. 


In  addition  to  full  compliance  with  HLA,  the  innovative  architectural  concept  that  was  developed  supports 
the  key  capabilities  required  for  future  C2-Simulation  interoperability  applications  : 

•  An  abstraction  layer  (e.g.  TNO-RCI  middleware)  and  a  code  generator  hiding  complexities  of  the 
underlying  simulation  interoperability  standards  and  enabling  simulation  protocol  migration  with 
minimal  changes  to  the  functional  implementation. 

•  A  structured  development  process  (the  FEDEP  [5]),  supported  by  appropriate  tools,  enabling 
migration  of  legacy  simulations  and  COTS  products  to  the  new  standard  architecture; 

•  The  Gateway  approach  as  the  optimal  solution  to  allow  interoperability  between  the  different 
worlds  that  C2  and  Simulation  are  today.  It  is  unlikely  that  one  single  standard  for  all  information 
exchange  between  systems  is  achieved  in  the  near  future,  even  if  we  restrict  the  ‘universe’  to 
NATO  C4I  systems. 

The  (completion  of  the)  design  and  the  development  of  the  C2WS  falls  outside  the  scope  of  our  project. 
However,  we  do  believe  that  future  C2  systems  will  include  the  design  requirement  for  interoperability 
with  simulations  and  the  results  of  our  project  will  therefore  influence  the  development  direction  of  the 
C2WS.  The  C2WS  is  on  its  way  to  become  a  useful  and  exciting  new  C2  system,  reaching  out  to  the 
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useful  and  exiting  new  simulation  standard  HLA. 

The  RNLA  is  planning  to  support  staff  training  with  the  Midlife  Update  (MLU)  of  KIBOWI.  This  MLU  is 
now  being  developed  by  TNO-FEL.  The  MLU  will  have  the  following  additional  features: 

•  The  MLU  is  coded  in  JAVA,  this  provides  platform  independence  (e.g.  Windows,  Linux,  Unix) 
and  eases  maintenance. 

•  The  MLU  is  internet  based  (TCP/IP).  This  makes  remote  training  with  an  internet  connection 
possible. 

•  The  MLU  provides  multiple  modes  of  use;  e.g.  the  warfighter  setting  ‘train  as  you  fight’  and  the 
classroom  setting. 

The  demonstrator  will  be  developed  into  a  fully  operational  coupling  between  the  C2WS  and  the  MLU  of 
KIBOWI.  The  first  application  will  be  support  for  staff  training.  The  Gateway  will  be  extended  with  more 
sophisticated  filters  and  features  that  allow  instructor  control  over  which  entities  are  transferred  (e.g.  blue 
only)  and  provide  additional  options  to  delay  the  transfer  of  ‘red’  unit  position  updates  as  if  these  were  the 
result  of  observations. 

Future  research  work  will  focus  on  the  use  of  KIBOWI  as  an  operational  support  tool  for  the  C2  process. 
KIBOWI  will  evaluate  and  analyse  COA’s  prepared  on  the  C2WS.  This  type  of  simulation  based  decision 
support  tool  provides  the  commander  with  a  range  of  new  possibilities.  This  next  version  of  the 
demonstrator  will  require  a  ‘two-way’  communication  between  the  C2WS  and  KIBOWI. 
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ABSTRACT 

Modelling  and  Simulation  (M&S)  is  a  powerful  tool  that  is  used  to  support  training  and  analysis  of 
military!  operations,  development  of  military >  concepts  and  gradually,  it  is  becoming  an  integral  part  of 
modern  C3I  systems.  As  the  web  has  evolved,  new  ways  of  carrying  out  modelling  and  simulation  and 
realizing  C3I  systems  have  emerged.  These  achievements  address  some  of  the  research  issues  considered 
vital  for  future  development  of  the  M&S/C3I  domain.  Firstly,  web  related  technologies  provide  means  of 
overcoming  the  interoperability  barriers,  for  example  through  standardized  data  exchange  formats  (such 
as  XML),  platform  independent  software  (for  example  Java)  and  shared  knowledge  of  a  domain 
(semantics) .  Secondly,  networked  environments  offer  ways  of  setting  up  virtual  organisations,  sharing 
common  goals  and  interests,  to  efficiently  collaborate  in  problem  solving.  Finally,  computer  networks 
promote  efficient  sharing  of  resources,  which  for  example  could  increase  the  reuse  of  existing  models  or 
utilize  idle  processing  capacity  of  computers. 

At  the  Swedish  Defence  Research  Agency  (FOI)  there  is  ongoing  research,  targeting  the  role  of 
network/web  based  technologies  in  M&S,  to  support  defence  communities  in  their  work.  Our  vision 
comprises  an  environment  supporting  the  entire  M&S-process,  including  conceptualization,  scenario 
definition,  design,  development  and  execution.  All  these  tasks  should  be  maintained  by  a  framework  for 
collaboration,  which  lets  users;  developers,  analysts,  administrators  etc,  jointly  work  on  a  project.  During 
the  first  phase  of  this  research  focus  has  been  on  efficient  resource  sharing  and  means  of  collaboration. 
Through  experimental  research  and  implementation  of  a  prototype  (NetSim),  methods  and  techniques 
have  been  identified  to  form  a  framework  for  collaborative  work,  resource  management  and  distributed 
execution. 

Following  current  trends  within  development  of  networked  applications,  decentralized  (Peer-to-Peer) 
solutions  were  of primary  focus  when  implementing  the  prototype.  Based  on  the  open  source  Peer-to-Peer 
platform  JXTA,  two  distinct  components  of  our  envisioned  system  were  implemented,  namely;  a 
decentralized  resource  management  system  deploying  a  network  of  workstation  for  execution  of  HLA 
federations  and  a  collaborative  environment  for  joint  modelling  of federations.  Our  results  show  that  the 
utilization  of  Peer-to-Peer  concepts  for  resource  sharing  and  collaboration  are  favourable  in  terms  of 
scalability,  robustness  and  fault  tolerance.  The  technology >  allows  formation  of  virtual  organisations 
without  the  need  of  intermediate  resources  like  centralized  and  powerful  sen’ers.  However,  some  aspects 
of  our  implementation  temporarily  rely  on  central  control,  thereby  diminishing  the  benefits  of  the  Peer-to- 
Peer  paradigm.  Future  research  will  therefore  address  distributed  algorithms  for  synchronisation  of 
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collaborative  work  and  a  more  flexible  and  extendable  approach  to  resource  management.  Furthermore, 
as  many  studies  have  pointed  out  before,  one  of  the  great  challenges  of  any  type  of  Peer-to-Peer  system  is 
discovery  and  matching  of  resources.  This  is  an  area  that  deserves  great  attention  when  planning  for  the 
next  generation  C3I/M&S  tools. 


1  INTRODUCTION 

C3I  systems  of  the  future  Network-Centric  Defence  are  dependant  of  the  network  and  require 
interoperability  between  different  components  of  the  system.  During  the  past  decades  the  modelling  and 
simulation  (M&S)  community,  particularly  the  area  of  distributed  simulation,  has  explored  the  possibility 
of  coupling  live  and  simulated  systems  in  joint  exercises  and  hence  addressed  the  interoperability  issues 
from  many  perspectives.  Therefore,  many  of  the  challenges  that  future  C3I  systems  are  facing  have 
already  been  dealt  with  by  the  M&S  community. 

M&S  as  an  integrated  part  of  C3I  systems  could  provide  means  for  decision  support,  simulation  based 
acquisition,  planning,  training,  etc.  Furthermore,  M&S  could  be  employed  as  a  tool  for  development  of 
C3I  systems,  e.g.  for  studies,  test  and  verification.  The  mutual  benefit  of  a  close  collaboration  between  C3I 
and  M&S  systems  has  been  identified  and  discussed  during  recent  years  [1]  and  the  Fligh  Level 
Architecture  (FILA)  has  been  suggested  as  a  mean  to  interface  and  increase  interoperability  between  the 
two  systems. 

The  Fligh  Level  Architecture  (LILA)  is  an  IEEE1  standardized  architecture  (HLA  1516),  that  provides 
means  of  connecting  independently  developed  components  (federates)  to  form  simulations  (federations). 
A  simulation  is  formed  by  connecting  individually  developed  components  to  a  Run-Time  Infrastructure 
(RTI),  which  implements  the  HLA  standard.  The  RTI  resembles  a  distributed  operating  system  for 
simulations  by  providing  services  that  enable  interaction  between  participating  components  [2]. 

Integrated  computer  based  decision  support  tools  have  also  been  identified  as  an  important  part  of  future 
C3I  systems  [3].  The  fundamental  idea  is  to  make  decisions  faster  and  at  the  same  time  improve  the 
quality  of  the  decisions  made.  Tools  that  are  accomplishing  this  are  generally  based  on  simulation 
systems,  which  often  require  interoperability  and  collaboration  between  different  actors,  such  as  decision¬ 
makers,  field  commanders,  and  technical  staff  etc.  To  realize  these  ideas  efforts  have  been  made  within  the 
area  of  computer  based  collaboration,  enabling  sharing  of  various  resources,  work  areas,  tools  and 
environments.  These  techniques  will  not  act  as  a  substitute  for  real  human-human  work,  but  can  be  used 
for  bridging  distances  and  increasing  and  facilitating  cooperation. 

An  evolving  technology  that  could  provide  a  fundament  for  modem  C3I  systems  is  Peer-to-Peer  (P2P)  [4, 
5].  The  technology  offers  advantages  such  as  live  peer  interaction  and  collaboration,  ad-hoc  networking 
and  robust  and  fault-tolerant  systems  through  redundant  application  and  communication  paths.  P2P- 
technologies  aim  at  utilization  of  resources  at  the  edges  of  Internet  as  opposed  to  the  traditional  client- 
server  model.  P2P  can  be  seen  as  an  alternative  network  architecture  that  doesn’t  exclude,  but  does  not 
naturally  build  upon  centralized  solutions  [6].  Essentially,  P2P  is  about  community  and  mutual  sharing  of 
resources,  by  organizing  nodes  into  groups  sharing  common  interests  and  goals. 

The  aim  of  this  paper  is  to  give  an  overview  of  work  related  to  web/network  based  modelling  and 
simulation  carried  out  at  the  Department  of  Systems  Modelling,  Swedish  Defence  Research  Agency. 
Moreover  it  provides  an  insight  in  ongoing  research  in  this  area  and  its  relation  with  integrated  M&S/C3I 
systems. 


1  The  Institute  of  Electrical  and  Electronics  Engineers 
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2  BACKGROUND 

2.1  Interoperability 

Connecting  systems  of  various  types  developed  for  different  purposes,  during  different  technological  eras 
and  for  different  platforms,  inflicts  major  difficulties,  especially  in  terms  of  interoperability.  It  is  required 
that  systems  are  capable  of  communicating  between  them,  but  also  that  the  communication  is  semantically 
and  syntactically  agreed  upon.  If  these  basic  requirements  are  not  met,  systems  may  interoperate  for  the 
wrong  reasons.  The  problem  of  interoperability  is  important  to  address  in  the  management  of  highly 
distributed  systems  like  distributed  simulations  and  C3I  systems.  The  issue  of  interoperability  has  been  of 
major  concern  within  the  modelling  and  simulation  community  for  some  time  now.  Already  during  the 
80’s,  efforts  were  made  to  standardize  distributed  simulations  to  facilitate  interoperability  among 
simulators,  simulation  models  etc.  The  efforts  made  and  experience  gained  in  this  forum,  are  definitely 
worth  considering  when  planning  for  and  developing  integrated  future  C3I  -  M&S  systems.  Moreover,  the 
rapid  development  of  web/network  related  technologies  brings  new  possibilities  for  overcoming  the 
interoperability  barriers  and  problems  related  to  availability  and  management  of  resources.  For  example, 
through  new  ways  of  exchanging  data  (XML),  distributing  resources  (P2P  and  Grid  computing),  and 
assuring  semantic  and  syntactic  correctness  (Semantic  Web  initiative1). 

2.2  The  NetSim  project 

In  2001  a  project  was  initiated  at  the  Department  of  Systems  Modelling,  FOI,  with  the  goals  to  manage 
and  facilitate  some  of  the  issues  concerning  simulation  interoperability,  availability  and  reusability.  The 
project  was  called  WebSim,  and  focused  on  the  area  of  web-based  M&S.  It  produced  interesting  result 
regarding  adapting  legacy  simulations  to  the  web,  and  also  concerning  implementing  HLA  federations  for 
web-based  composition  and  execution.  Some  of  the  work  was  reported  in  [7], 

As  a  follow-up  to  WebSim  the  NetSim  project  was  formed.  NetSim  is  a  shortening  of  the  full  name  A 
Network  Based  Environment  for  Modelling  and  Simulation.  The  new  project  does  not  reject  the  ideas  of 
web-based  M&S,  but  instead  extends  the  concept.  The  main  directions  are  to  investigate  decentralized 
solutions  for  M&S  in  general,  both  web-based  solutions  and  other  possibilities.  For  this  cause  a  prototype 
environment  is  being  developed.  It  is  intended  to  provide  functionality  and  tools  for  the  complete  M&S 
life  cycle,  all  the  way  from  design  and  simulation  modelling,  to  execution  and  documentation.  The  NetSim 
environment  shall  also  provide  access  to  distributed  resources  such  as  simulation  models,  various  data,  or 
even  CPU  usage,  as  aid  for  M&S  activities. 

NetSim  is  intended  for  use  within  several  different  defence  systems.  It  will  support  computer-based 
collaborative  work,  such  as  shared  work  areas  and  means  of  communication.  This  means  that  NetSim  will 
not  only  work  as  a  common  platform  for  M&S,  but  also  as  a  place  of  meeting  for  (M&S)  people.  In  the 
computer  environment,  software  developers,  Subject  Matter  Experts  (SMEs),  soldiers  and  VV&A  people 
may  meet,  and  use  and  share  each  others’  resources  and  expertise.  In  modem  and  future  defence  systems 
M&S  is  used  as  technical  aid  for  decision  making,  Simulation  Based  Acquisition  (SBA),  logistics 
planning  and  military  training  etc.  Hence,  NetSim  could  constitute  an  excellent  tool  for  those  systems  and 
activities,  and  for  activities  where  M&S  is  not  currently  used,  but  would  be  beneficial  if  made  possible. 
An  example  of  this  is  the  support  for  mobile  clients  such  as  PocketPCs.  This  allows  people  on  the  move  to 
interact  with  the  environment.  Hence  a  soldier  may  receive  direct  access  to  data  and  information  about 
supplies  and  routes,  and  may  collaboratively  plan  or  decide  what  forthcoming  actions  to  take.  This  also 
means  that  dynamic  and  actual  data  can  be  transmitted  back  to  the  base,  and  more  optimized  and  well- 
planned  decisions  can  be  made  easily.  The  NetSim  environment  will  allow  people  (nodes)  within  a 
network  to  collaborate  through  their  computers,  which  makes  it  easier  to  create  a  common  picture  of  the 


1  The  semantic  web  is  a  web  of  machine-readable  infonnation  [8], 


RTO-MP-MSG-022 


10-3 


NetSim  -  A  Network  Based  Environment  for  Modelling  and  Simulation 


ORGANIZATION 


situation/problem  to  handle,  and  supplied  direct  contact  between  all  actors  concerned.  It  hereby  allows 
immediate  access  to  the  competence  and  expertise  needed. 

2.3  The  NetSim  environment  prototype 

At  present  a  NetSim  prototype  is  implemented.  The  prototype  is  not  yet  complete,  but  it  demonstrates 
useful  functionality  and  what  the  environment  can  be  used  for  if  employed  in  defence  systems.  It  is 
implemented  as  a  lightweight  Java  application,  in  which  a  user  retrieves  access  to  M&S  tools  and 
distributed  resources  within  a  local  network.  In  order  to  let  various  kinds  of  users  access  NetSim,  who  may 
be  located  in  different  computer  environments,  a  set  of  requirements  were  identified  and  followed  during 
the  design  phase.  These  declare  that  the  implementation  should  be: 

•  Flexible  -  Supporting  different  users  with  varying  computer  capacity  and  properties  to  utilize  the 
system 

•  Scalable  -  In  critic  situations  the  number  of  users  must  not  affect  the  system  capacity 

•  Platform  independent  -  As  much  as  possible  the  implementation  should  be  kept  platform 
independent 

•  Technology  independent  -  The  result  of  our  work  is  primarily  the  concepts  being  designed,  not 
the  implementation.  Hence  the  solution  is  kept  as  technology  independent  as  possible 

•  Extensible  -  The  infrastructure  must  allow  for  further  integration  of  new  systems  and 
functionality 


All  simulation  modelling  and  execution  is  today  perfonned  according  to  the  HLA  for  purposes  of  project 
directives.  The  system  is  based  on  a  distributed  infrastructure  implemented  with  P2P  technology,  see  2.5  - 
2.6,  which  provides  means  for  resource  sharing  and  distributed  computing  among  others.  It  allows  users  to 
search  for,  locate  and  access  distributed  resources  and  users  in  the  network.  Resources  may  in  this  case  be 
anything  from  simulation  models  to  CPU  usage.  Within  NetSim  only  a  few  simple  tools  are  currently 
provided,  such  as  a  text  chat,  an  application  for  managing  resources,  and  a  graphical  modelling  tool,  in 
which  a  user  may  compose  HLA  federations  out  of  HLA  federates  residing  within  the  network.  A 
snapshot  of  the  graphical  M&S  tool  is  shown  in  figure  2.1.  Users  can  also  run  and  view  the  composed 
HLA  federations  from  the  environment.  The  execution  is  performed  transparently  to  the  user,  within  the 
P2P  network,  through  efficient  utilization  of  idle  processing  capacity  in  desktop  computers. 

2.4  Areas  of  research 

When  designing  NetSim,  we  identified  some  areas  of  significance  to  networked  environments  and 
network  based  M&S  in  particular.  We  decided  to  focus  on  a  few,  which  are: 

•  Component-based  M&S  -  Allowing  reusable,  easily  distributed  simulations 

•  Standards  and  techniques  for  M&S  -  Distributed,  reusable  simulations  set  high  requirements  on 
interoperability 

•  Thin  clients  -  Involving  not  only  PCs  and  web-based  clients  in  the  M&S  system,  but  also 
PocketPCs  and  others 

•  Collaborative  environments  -  Environments  that  provide  a  common  picture  of  the  problem  to 
solve.  Involving  problems  of  maintaining  consistency  and  control  within  the  collaboration  group 

•  Resource  utilization  -  Efficient  ways  of  utilizing  distributed  resources,  through  efficient  resource 
description  and  allocation 
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Of  the  issues  listed  above,  the  last  two  have  been  the  key  issues  in  previous  and  current  work.  The 
collaborative  work  is  described  in  chapter  3,  and  the  resource  utilization  in  chapter  4.  More  technical 
descriptions  of  these  have  been  presented  in  two  papers  [9,  10]. 
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Figure  2.1 :  Snapshot  of  graphical  modelling  tool  in  NetSim.  Users  may  (collaboratively  or  not) 
compose  HLA  federations  out  of  HLA  components  (federates)  residing  in  the  network. 


2.5  Peer-to-Peer  Based  Resource  Sharing 

Peer-to-Peer  (P2P)  as  a  concept  for  computer  communication  is  nothing  new.  In  the  early  sixties,  the 
pioneers  of  ARPANET  formulated  their  vision  of  a  future  computer  network  comprising  host-to-host 
capabilities.  In  their  vision  all  connected  nodes  were  equal  in  terms  of  functionality  and  could  access 
resources  from  any  other  computer  on  the  network  [11],  These  early  ideas  have  not  greatly  influenced  how 
the  Internet  is  used  today.  The  dominating  architecture  is  the  client-server  model,  where  resources  of 
various  kinds  tend  to  accumulate  at  dedicated  centres.  Large  parts  of  the  Internet  remain  unused,  as 
network  traffic  around  certain  spots  shows  increasing  activity.  However,  in  the  past  years  ideas  and 
technologies  have  been  put  forth  that  promote  the  idea  of  distributing  resources  through  use  of  P2P 
technologies.  The  distribution  of  resources  is  advantageous  from  many  aspects;  it  reduces  the  occurrence 
of  bottlenecks,  minimizes  possible  system  downtime  and  increases  system  availability  and  robustness  etc. 

P2P  has  definitely  made  a  great  impact  on  how  ordinary  desktop  computers  may  communicate  and 
exchange  various  resources.  This  is  especially  true  for  the  so  called  file  sharing  applications,  although  they 
are  heavily  questioned  in  terms  of  legal  property  rights.  However,  some  more  academic  projects  have 
successfully  confirmed  the  strength  of  P2P  for  distributed  computing.  The  Intel  Philanthropic  P2P 
program  has  demonstrated  utilization  of  idle  processing  capacity  in  desktop  computers  to  solve  problems 
within  the  medical  domain  [12],  whereas  the  SETI@Home  project  represents  a  successful  P2P  model  for 
distributed  computing,  used  for  processing  of  radio  astronomic  data  [13]. 
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2.6  JXTA 

JXTA  is  an  open-source  P2P  project,  initiated  by  Sun  Microsystems  in  2000,  providing  a  standardized  and 
platform  independent  P2P  platform  [14].  The  system  is  based  on  XML1  messaging  through  employment  of 
six  protocols.  Any  piece  of  Internet  connected  hardware  implementing  these  protocols,  or  a  subset  of 
them,  can  participate  in  a  JXTA  network.  Nodes  on  the  JXTA  network  are  called  peers.  Peers  form 
peergroups,  based  on  common  interests  and  goals,  within  which  the  participants  share  resources  [11].  The 
JXTA  platform  provides  a  rich  set  of  P2P  features,  thus  simplifying  the  development  of  distributed 
systems. 


3  COMPUTER  SUPPORTED  COLLABORATIVE  M&S 

3.1  Computer-based  collaboration  and  M&S 

Since  the  science  and  hype  of  Virtual  Reality  (VR)  broke  through,  huge  interest  and  activities  have  been 
conducted  within  the  field.  Despite  the  interest  and  future-thinking  about  the  area,  3D  virtual  worlds  have 
not  yet  reached  into  our  offices  and  everyday  lives.  VR  is  instead  a  part  of  the  larger  field  of  using 
computers  to  support  human-human  collaboration,  an  area  which  has  gained  far  more  usage  than  VR  in 
itself,  due  to  its  availability  and  range  of  technical  possibilities.  Groupware,  videoconferencing  and  shared 
project  areas  are  just  a  few  of  the  kind  of  products  used  for  these  purposes.  Computer-based  collaboration 
can  assist  in  joining  people  and  organizations  in  the  same  environment,  allowing  people  to  share  not  only 
resources  but  also  work  areas,  tools  and  environments.  Though  computer-realized  collaboration  may  never 
represent  a  substitute  for  real  human-human  work,  it  can  be  used  for  bridging  distances  and  increasing  and 
facilitating  cooperation. 

These  advantages  are  applicable  within  other  areas  as  well.  If  considering  collaborative  M&S,  sometimes 
referred  to  as  CMAS,  it  could  help  joining  people  like  software  engineers,  VV&A  expertise  and  others  in  a 
common  computer  environment.  With  CMAS  a  project  team  could  cooperate  on  M&S  problems,  with 
immediate  support  from  SMEs,  and  with  the  customer  supervising  the  activities,  no  matter  if  they  are 
located  on  the  same  place  or  not.  This  improves  and  assures  quality  of  work  and  enhances  work  efficiency. 
Within  the  defence  in  general,  computer-based  collaboration  is  a  very  interesting  issue,  since  often 
military  personnel  are  spread  over  long  distances.  A  key  feature  here  is  the  possibilities  of  increasing  the 
availability  of  competence  and  expertise,  an  issue  which  could  be  of  considerable  importance  within  critic 
systems  for  C3I  and  other  domains. 

3.2  Infrastructure  for  CMAS  in  NetSim 

One  of  the  main  goals  of  NetSim  is  to  provide  support  for  collaborative  work.  If  complying  with  the 
definition  of  Collaborative  Virtual  Environments  (CVEs)  as  described  in  [16],  a  CVE  shall  provide  shared 
information,  tools  and  communication  access,  and  need  not  provide  a  3D  visual  environment.  The  work  of 
NetSim  focus  on  constructing  an  every-day  used  defence  environment,  for  practical  collaborative  M&S, 
which  is  why  we  dismissed  the  thoughts  of  flashy  3D  worlds  and  emphasized  on  reducing  complexity  and 
enhancing  availability  instead.  This  increases  the  possibilities  of  integrating  the  infrastructure  in  already 
existing  systems,  such  as  for  example  C3I  systems.  Thus  a  flexible  and  lightweight  infrastructure  for 
CMAS  was  designed.  A  first  prototype  has  been  implemented  and  integrated  within  the  NetSim 
environment.  It  mainly  constitutes  a  middle  layer,  between  a  Java  GUI2  and  the  JXTA  P2P  network,  and  is 


1  The  Extensible  Mark-up  Language  (XML)  is  a  mark-up  language  designed  to  describe  and  encapsulate  data.  It  has  become  a 
major  technique  for  exchanging  data  in  heterogeneous  environments,  since  it  provides  a  platform  and  programming  language 
neutral  data  format  [15], 

2  GUI  -  Graphical  User  Interface,  the  visual  application  in  which  the  user  interacts  with  the  environment. 
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based  on  two  components.  The  first  component  is  a  core,  the  Collaboration  Core  (CC),  containing 
functionality  for  collaborative  work,  implemented  using  P2P  technology.  The  second  is  an  HLA  coupling 
that  provides  means  of  collaborative  simulation,  and  is  implemented  on  top  of  the  CC.  These  are  further 
described  below,  and  were  describes  in  detail  in  [9]. 

3.2.1  Collaboration  Core 

The  CC  allows  users  to  collaborate  on  M&S  activities,  or  any  kind  of  activities  that  the  environment 
supports.  Currently  it  provides,  among  others,  functionality  for  creating,  searching  for  and  joining 
collaboration  groups1.  The  collaboration  groups  are  based  on  the  concept  of  JXTA  peer  groups,  and  are 
used  for  grouping  collaboration  participants  and  for  utilizing  group  functionality  and  mechanisms  for 
managing  collaboration  (described  in  3.3).  A  group  provides  group  specific  settings  and  information,  and 
specific  services  and  tools  that  may  be  used  (collaboratively)  within  that  specific  group.  The  tools  can  be 
anything  from  communication  means,  such  as  text  chats  and  web-cams,  to  advanced  M&S  or  other  tools. 
The  infrastructure  allows  for  further  extension  and  integration  of  tools  but,  as  mentioned  before,  it  is 
currently  just  a  prototype.  The  tool  that  is  demonstrated  and  used  today  is  a  simple  shared  graphical  tool, 
in  which  users  may  collaboratively  compose  HLA  federations  out  of  HLA  federates.  Users  cooperate 
through  using  communication  tools  such  as  chats  and  web  cams.  In  the  current  application,  a  chat  is 
provided  within  the  application  and  a  web  cam  is  used  externally.  The  CC  allows  participants  to  share 
views,  meaning  that  all  see  the  same  thing  at  the  same  time  within  a  work  area  or  tool.  Hence,  they  see  the 
same  actions  and  changes  at  the  same  time,  similar  to  sharing  tools  over  a  network,  but  in  a  decentralized 
way  through  using  P2P  technology  (JXTA). 

3.2.2  HI, A  coupling 

The  second  prototype  component  is  the  HLA  coupling  that  supplies  the  user(s)  with  a  graphical  interface 
in  which  the  result  of  the  distributed  simulation  is  visualized.  All  participants  in  a  group  see  the  simulation 
and  the  same  states  of  the  simulation  at  the  same  time.  This  feature  is  implemented  using  the  HLA 
framework  rather  than  based  on  P2P  technology,  for  reasons  discussed  below.  Users  may  stop,  play  and 
step-forward  the  simulation,  and  all  group  participants  receive  the  same  new  states  if  the  simulation  is 
changed  or  interacted  with.  This  demonstrative  collaborative  simulation  can  be  of  considerable  use  for 
military  planning,  distance  education,  strategy  demonstration,  or  when  using  M&S  as  basis  for  decision 
support  etc. 

3.3  Challenging  issues  and  implemented  solutions 

During  the  work  some  challenging  issues  were  identified  that  exist  within  collaborative  systems,  and 
which  are  naturally  common  for  most  distributed  systems  [17],  such  as  mechanisms  for  maintaining 
information  consistency  and  fault  tolerance.  It  is  challenging  to  synchronize  and  coordinate  actions  and 
interactions  within  a  group,  i.e.  to  guarantee  that  all  participants  have  the  same  common  picture  at  the 
same  time,  and  that  no  changes  or  actions  on  the  same  object  collide.  Another  issue  was  the  (collaborative) 
simulation,  since  different  platforms  demand  various  solutions  for  the  same  visualization.  This  requires 
generic  interfaces  for  simulation  and  tools,  which  comply  with  the  computer  capacity  and  properties  in 
use,  problems  that  are  not  fully  addressed  in  current  work.  Moreover  network  properties  may  constitute  a 
problem  due  to  delays  and  overhead,  another  issue  not  covered  yet.  Challenging  issues  that  are  currently 
considered  are  presented  in  brief  below. 

3.3.1  General  infrastructure  for  collaboration 

Designing  an  infrastructure  for  collaborative  work  in  an  efficient  way,  which  is  extensible  for  integration 
of  new  functionality,  is  not  an  easy  thing.  A  usual  procedure  is  to  employ  a  server-centric  solution,  where 


'A 


user  can  be  a  member  of  any  number  of  groups. 
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the  server  (or  central  computer)  propagates  screen-dumps1  of  a  shared  work  area  (may  be  a  tool)  to  all 
participants.  This  is  used  by  products  such  as  VNC2  and  NetMeeting3  and  can  be  easily  applied  but  is 
inefficient  due  to  overhead  among  other  things.  Our  implementation  (the  CC)  provides  a  more  optimized 
solution  that  is  principally  distributed  and  that  considers  changes  in  objects’  states,  and  transmits  the  state 
changes  only,  to  all  participants.  On  the  other  hand  our  solution  sets  high  requirements  for  integration  of 
new  tools  into  the  infrastructure,  which  may  have  to  be  generalized  in  future  work. 

The  distributed  infrastructure  was  implemented  using  built-in  group  functionality  in  the  P2P  framework 
JXTA  [14].  A  new  kind  of  group  was  created,  the  CollaborationGroup,  which  is  an  implementation  that 
extends  the  group  concept  and  includes  services  for  group  functionality  etc.  When  a  new  group  for 
collaboration  is  created,  a  new  such  group  is  started,  instead  of  an  ordinary  PeerGroup.  When  joining  a 
collaboration  group  users  receive  a  handle  to  a  shared  communication  channel.  Thus,  all  actions  produced 
within  a  group  are  propagated  and  managed  along  this  channel. 

3.3.2  Coordinating  participant  actions 

Collaborative  modelling  requires  real-time  interaction.  The  actions  produced  must  be  coordinated  and 
synchronized  among  the  participants.  For  this  we  applied  a  coordinator-based  scheme,  which  is  a  widely 
used  solution  to  the  problem.  A  coordinator  represents  the  node  through  which  all  actions  are  passed  and 
coordinated.  When  a  user  wishes  to  perform  an  action  on  an  object  in  the  shared  area,  it  requests  the 
coordinator  for  permission.  If  no  other  user  wants  to  act  upon  the  same  object,  the  request  is  processed 
immediately  and  all  users  receive  the  new  shared  state,  without  causality  errors  or  action  conflicts.  This 
results  in  a  temporary  centralized  solution,  which  is  easily  implemented  but  not  optimal  if  a  lot  of 
information  has  to  be  coordinated.  Coordination  and  synchronization  would  rather  be  managed  in  a 
distributed  fashion  (more  complex).  Our  solution  also  brings  that  client  synchronization  is  managed 
immediately,  rather  than  when  it  is  necessarily  needed,  i.e.  when  users  need  to  have  the  same  views.  If  all 
participants’  views  are  coordinated  only  when  needed,  a  better  and  more  scalable  implementation  would 
be  achieved.  Thus,  these  two  issues  are  of  concern  for  current  and  future  work. 


3.3.3  Synchronizing  collaborative  simulation 

Collaborative  simulation  does  not  require  such  frequent  coordination  of  interactions  as  other  M&S 
activities  do,  since  the  user  interactions  during  simulation  are  most  likely  simple  ones  such  as  stopping  or 
pausing  the  simulation.  Thus  coordination  is  not  an  issue  here.  In  contrast,  a  high  amount  of  simulation 
information  needs  to  be  transmitted  to  and  synchronized  between  the  users,  in  order  to  guarantee  that  all 
users  see  the  same  state  of  the  simulation  at  all  times.  This  means  that  it  may  not  be  possible  for  the 
information  to  be  continuously  synchronized  due  to  the  overhead  and  time  delays  it  may  cause.  In  current 
implementation,  the  clients’  views  are  synchronized  continuously  (synchronously),  and  would  preferably 
be  exchanged  with  more  efficient  solutions.  The  issue  of  effective  synchronization  was  highlighted  in 
previous  work  [9],  and  is  an  important  part  of  current  work  (discussed  below). 

3.4  Synchronizing  collaboration  participants  using  HLA 

When  implementing  functionality  for  collaborative  simulation,  the  design  choice  was  made  to  use  HLA 
instead  of  JXTA  for  synchronizing  participant  visualization  and  user  interaction  in  the  simulation.  One  of 
the  reasons  was  that  HLA  provides  excellent  functionality  for  time  management  and  means  for  federation 
synchronization  [20].  The  HLA  coupling  was  implemented  as  a  layer  on  top  of  the  CC,  as  mentioned 
above.  Each  user  application  comprises  HLA  functionality,  which  acts  as  an  HLA  federate,  called  the 
Visualizer  federate.  The  Visualizer  subscribes  to  the  simulation  objects  and  attributes  necessary  for 


1  Screen-dump  =  a  momentary  image  taken  of  the  screen. 

2  VNC  -  Virtual  Network  Computing  is  a  free  product  for  sharing  work  areas  [18], 

NetMeeting  is  a  product  that  allows  projects  to  use  shared  work  areas  and  tools  [19], 
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visualizing  the  federation,  in  order  to  illustrate  the  accurate  simulation  result  in  the  client’s  window.  The 
Visualizer  federates,  i.e.  the  clients’  views,  are  synchronized  using  HLA  built-in  mechanisms.  User 
interactions  with  the  simulation  are  handled  through  the  Visualizer  and  are  forwarded  to  the  rest  of  the 
federation.  An  HLAManager1  reflects  the  interaction  event,  and  makes  sure  the  proper  action  is  processed, 
as  for  example  pausing  the  federation  or  stepping  it  forward.  Federations  used  today  are  based  on  time- 
stepped  federates  and  the  synchronization  is  performed  synchronously  in  fixed  time  intervals.  This  is 
neither  efficient  nor  scalable,  since  it  results  in  a  great  number  of  synchronization  points,  no  matter  if 
anything  important  has  occurred  or  not.  This  may  in  turn  cause  time  delays  and  unnecessary  overhead. 

In  order  to  investigate  more  efficient  ways  of  synchronizing  the  federation  for  our  purposes,  current  work 
emphasizes  on  facilitating  the  use  of  time  management  (TM)  in  HLA.  A  middle  layer  on  top  of  the 
HLA/RTI  is  being  designed  and  implementation  of  it  has  been  initiated,  which  is  somewhat  similar  to 
approaches  made  such  as  [21]  and  [22],  The  layer  is  included  and  utilized  in  each  federate,  and  comprises 
functionality  for  TM  and  various  synchronization  protocols2.  A  schematic  view  of  this  is  presented  in 
figure  3.1.  Protocols  that  are  intended  are  first  of  all  simple  solutions  for  synchronous  and  conservative 
simulation,  but  optimistic  protocols  are  also  considered.  The  layer  is  designed  to  relieve  the  simulation 
developer  from  some  of  the  HLA  specific  logic.  It  will  also  provide  various  ways  of  synchronizing 
federations  and  estimating  performance,  which  allows  flexibility  of  synchronization  protocols.  It  is 
intended  to  support  us  in  evaluating  and  implementing  efficient  synchronization  for  the  collaborative 
infrastructure,  but  can  be  of  use  within  other  areas  as  well. 


Figure  3.1 :  Schematic  picture  of  middle  layer  for  RTI/HLA  specific  logic. 


3.5  Conclusions 

Applying  JXTA  P2P  functionality  for  coordinating  and  supporting  collaborative  simulation  modelling 
turned  out  to  be  a  good  solution.  The  concept  of  JXTA  peer  groups  and  functionality  for  groups  such  as 
membership,  authentication,  group  services  etc.  was  very  beneficial  within  this  context.  The  group  concept 
was  extended,  and  gave  us  the  result  desired.  But  JXTA  was  by  the  time  of  work  not  a  fully  complete 
technology3,  and  was  not  very  easily  managed. 


1  The  HLAManager  is  used  for  facilitating  some  functionality  within  a  federation,  such  as  controlling  synchronization  and 
managing  the  federation.  This  is  not  crucial  and  everything  may  be  carried  out  within  each  federate  instead,  but  it  facilitates 
federation  development. 

2  The  middle  layer  is  nothing  necessary,  but  it  facilitates  working  procedures,  user  flexibility  and  provides  extra  functionality. 

The  latest  version  of  JXTA  is  2.0,  a  version  which  the  authors  of  this  paper  have  no  practical  experience  of  yet. 
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For  the  collaborative  modelling  a  centralized  coordinator-scheme  was  used.  Since  this  solution  is  not 
scalable  or  efficient,  it  can  be  done  more  efficiently  in  a  decentralized  way.  This  issue  is  considered  in 
current  work.  Also,  the  design  to  use  optimized  information  flows  (instead  of  screen-dumps)  proved  to  be 
good. 

For  synchronizing  and  visualizing  the  collaborative  simulation  the  HLA  framework  was  applied, 
something  that  proved  useful  but  needs  to  be  extended  regarding  flexibility  and  ease-of-use. 
Synchronizing  the  federation  synchronously  showed  non-efficient,  and  an  alternative  solution  is  currently 
designed  which  constitutes  a  flexible  middle  layer  between  HLA  and  the  federates. 

During  the  work  it  was  pointed  out  that  CMAS  can  be  of  considerable  use  within  the  defence,  such  as 
distance  education  and  military  planning.  This  holds  for  activities  that  use  M&S  as  basis  for  decision 
support  and  situations  when  presence  of  SME:s  may  not  be  physically  possible,  but  highly  desirable  etc. 


4  RESOURCE  MANAGEMENT 

4.1  Resource  Utilization  for  Distributed  Simulations 

As  part  of  the  NetSim  environment,  a  module  for  execution  of  HLA  federations  has  been  developed  based 
on  the  JXTA  P2P  platform,  described  in  section  2.6.  The  main  idea  of  this  module,  the  Distributed 
Resource  Management  System  (DRMS),  is  to  utilize  idle  processing  capacity  in  a  network  of  workstations 
for  distributed  simulations.  Furthermore,  it  should  provide  a  distributed  repository  for  storage  of 
simulation  components  and  associated  documentation.  Other  projects  have  explored  these  possibilities,  see 
for  example  [23],  but  then  often  based  on  the  client  server  model  for  management  of  resources  and  storage 
of  simulation  components. 

The  basic  idea  of  the  DRMS  is  that  desktop  owners  within  an  organisation  download  and  install  a  small 
client  that  under  certain  circumstances  share  resources  with  other  connected  nodes.  There  are  currently 
three  levels  of  involvements  for  connected  nodes.  First,  a  node  may  share  computing  capacity  for 
execution  of  HLA  federations,  referred  to  as  a  computing  resource  in  the  following  text.  Second,  a  node 
can  be  part  of  the  distributed  repository  for  sharing  of  content  (HLA  federates,  documentation  etc.). 
Finally,  a  node  may  share  both  computing  capacity  and  content.  The  desktop  owner  always  has  the  option 
to  withdraw  its  involvement  by  changing  a  switch  in  the  user  interface  or  by  closing  the  client.  Therefore, 
the  availability  of  resources  on  the  network  is  expected  to  change  fast  and  unpredictably  in  an  Ad-Hoc 
manner.  To  comply  with  this  the  system  includes  mechanisms  for  migration,  or  movement,  of  federates 
between  available  computing  resources  during  a  federation  execution.  Furthermore,  the  dynamic 
characteristics  of  the  network  calls  for  redundancy  (replication)  in  storage  of  simulation  components  to 
gain  access  to  the  same  set  of  federates  at  all  times.  However,  this  part  of  the  problem  has  not  yet  been 
fully  addressed  in  the  current  implementation. 

A  major  aspect  to  consider  when  implementing  any  type  of  P2P  based  system  is  discovery  and  matching 
of  resources.  The  first  problem  relates  to  the  basic  strategy  used  to  discover  the  presence  of  other 
nodes/resources  on  the  network.  Another  problem  to  handle  is  how  to  identify  those  resources  that  match 
certain  requirements. 

The  JXTA  platform,  and  thus  the  DRMS,  supports  three  different  mechanisms  for  identifying 
nodes/resources,  these  are  [24]: 
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No  discovery  -  using  this  approach,  nodes  rely  on  a  cache  of  previously  located  advertisements 
that  describe  the  features  of  resources.  This  is  implemented  by  broadcasting  advertisements  from 
nodes  at  regular  time  intervals 
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•  Direct  discovery  -  in  this  case  the  nodes  do  not  publish  any  advertisements  until  they  are  asked  to 
do  so,  i.e.  until  a  consumer  of  resources  broadcasts  a  resource  request  on  the  network.  This 
strategy  is  often  referred  to  as  flooding 

•  Indirect  discovery  -  using  this  approach  all  nodes  publish  their  advertisements  to  a  centralized 
catalogue.  The  consumer  node  locates  resources  by  requesting  the  catalogue.  However,  when  a 
consumer  has  identified  a  producer,  the  communication  is  performed  directly  between  involved 
parties 

We  have  not  yet  performed  any  measures  of  the  performance  of  these  three  approaches,  but  this  will  be 
addressed  in  future  work,  where  also  the  new  JXTA  2.0  release  will  be  taken  into  consideration. 

When  suitable  resources  have  been  identified  by  consumer  peers,  the  requirements  of  the  requests  have  to 
be  matched  against  the  features  of  available  resources.  At  present,  the  implementation  includes  simple 
mechanisms  for  this  activity.  First,  the  SOMs1  of  selected  federates  are  automatically  matched  to  assure 
simulation  interoperability.  Then  federates  are  mapped  to  available  computing  resources  i.e.  nodes  among 
the  list  of  available  resources  are  selected  and  assigned  jobs  to  execute  the  federates.  The  advertisements 
of  computing  resources  contain  node  specific  information,  for  instance  running  hardware,  software  etc. 
Using  this  information,  nodes  running  the  fastest  processors  are  chosen  to  execute  federates.  For  a  more 
technical  description  of  the  DRMS  see  [10]. 

The  present  approach  of  matching  simulation  components  to  form  simulations  and  mapping  individual 
components  to  computing  resources  is  rather  rudimentary.  There  is  a  need  to  enable  matching  of 
simulation  components,  not  only  at  the  architectural  level  (matching  of  SOMs),  but  also  at  a  higher  level. 
Furthermore,  it  is  also  important  to  describe  a  simulation  component  in  terms  of  its  requirements  on  the 
execution  environment,  and  likewise  describe  the  features  that  a  computing  resource  provides  for  a 
simulation  component.  This  calls  for  a  better  way  of  managing  meta-descriptions  of  resources  within  the 
NetSim  environment,  to  facilitate  efficient  searching,  matching  and  execution. 

4.2  Describing  Resources 

This  section  gives  an  overview  of  ongoing  and  future  research  topics,  aimed  at  extending  the  support  for 
metadata  in  the  NetSim  environment.  The  employment  of  meta-descriptions  of  resources  within  the 
NetSim  environment  is  especially  pronounced  during  three  activities;  searching  for  simulation 
components,  matching  simulation  components  and  during  execution  of  simulations.  The  role  of  metadata 
also  differs  greatly  between  these  activities,  which  will  be  explained  below.  However,  there  are  no  solid 
boundaries  between  the  uses  of  metadata  in  these  activities.  Certain  types  of  metadata  may  be  applicable 
in  all  three  cases. 

4.2.1  Searching  for  components 

In  this  activity  the  user/users  of  the  NetSim  environment  searches  for  available  simulation  components  or 
previously  assembled  simulations.  The  basic  requirement  on  metadata  supporting  this  process  is  a  well 
defined  class  structure,  identifying  subclass/superclass  relations.  This  enables  simple  queries  like  “all 
airplanes”  or  “all  fixed-wing  aircrafts”,  which  yields  all  components  which  are  subclasses  of  airplane  or 
fixed-wing  aircraft  respectively.  However,  note  that  this  classification  is  not  equal  to  the  implementation 
related  object  class  structure.  Furthermore,  the  components  should  be  described  in  terms  of  a  system-of- 
systems  view  where,  if  applicable,  a  component’s  relations  with  other  components  are  defined.  For 
instance  describing  that  system  A  and  system  B  may  integrate  to  form  the  superior  system  C.  Finally,  the 


SOM  is  the  short  term  for  " Simulation  Object  model",  and  is  the  documentation  and  definition  of  a  federate ’s  all  characteristics 
and  possible  interactions  etc. 
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metadata  infrastructure  should  support  descriptions  of  roles  or  capabilities,  which  enable  searches  in  the 
form  of  “air  based  transportation”  or  “underwater  surveillance”. 

4.2.2  Matching  components 

This  activity  represents  the  attempt  to  compose  simulations  out  of  a  number  of  components,  i.e. 
component  based  development.  This  area  is  sometimes  labelled  composability  and  has  been  investigated 
extensively  to  promote  model  reuse  and  interoperability.  According  to  [25]  composability  is 

“the  ability  to  combine  and  recombine  components  into  different  simulation  systems  for 
different  purposes.  ” 

Irrespective  of  matching  at  the  simulation  architectural  level,  for  instance  matching  of  SOMs  in  the  case  of 
HLA,  an  environment  supporting  component  based  simulation  development  should  include  extensive 
metadata.  This  is  to  guarantee  the  composition  of  valid  simulations  at  all  levels.  [26]  outlines  some  of  the 
fundamental  requirements  on  metadata  to  support  composability,  namely; 

Infonnation  about  the  model  as  a  software  component: 

•  Programming  language 

•  Communication  protocol 

•  Location  of  component 

Infonnation  about  the  model  as  a  simulation  component: 

•  Spatial  resolution 

•  Aggregation 

•  Temporal  resolution 

•  Fidelity 

•  Required  services 

4.2.3  Executing  simulation 

This  final  activity  involves  mapping  simulation  components  to  computing  resources  prior  to  and  during 
federation  execution,  i.e.  assign  jobs  to  various  nodes  in  the  network.  Metadata  that  should  support  this 
process  include  running  hardware  and  software  on  the  computing  resources  and  a  set  of  requirements 
imposed  by  the  simulation  components.  These  requirements  consist  of  information  such  as;  what  platfonn 
is  needed  to  run  the  component?  Is  a  specific  runtime-environment  needed  to  run  the  component?  How 
computing  intensive  is  the  component?  etc.  Note  that  this  process  is  not  only  required  prior  to  the 
execution.  Since  the  allocation  of  computing  resources  is  not  static,  it  is  necessary  to  perform  rescheduling 
from  time  to  time. 

4.2.4  Metadata  framework 

In  order  to  create  a  foundation  (or  framework)  for  metadata,  to  support  resource  consuming  systems 
(M&S  and  C3I  systems)  in  various  ways,  a  number  of  components  are  required: 

•  Meta-language  -  formal  semantics  and  syntax,  expressing  shared  and  common  understanding  of  a 
domain 

•  Metadata  repositoiy  -  supporting  uploading/downloading  of  metadata  through  standardized 
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protocols  (http,  SOAP  etc.),  consistency  checking  and  version  control 

•  Query’  language  -  supporting  complex  queries  on  the  metadata 

Figure  4.1  outlines  a  conceptual  view  of  a  framework  for  metadata  supporting  efficient  searching, 
matching  and  execution  within  the  NetSim  environment.  The  central  component  of  this  system  is  a 
repository  where  the  descriptions  of  resources  on  the  network,  simulation  components,  data  and 
computing  resources  are  stored.  The  resources  should  be  annotated  according  to  a  standard  for  data 
representation  augmented  with  the  shared  knowledge  of  the  domain.  Activities  within  the  NetSim 
environment  are  then  supported  by  extraction  of  meta-descriptions  from  the  repository,  followed  by  semi- 
automated  reasoning  using  the  knowledge  expressed  by  these  descriptions 

There  are  a  number  of  efforts  that  could  provide  a  basis  for  our  envisioned  metadata  framework,  for 
instance  the  Resource  Description  Framework  (RDF)  [27],  the  Web  Ontology  Language  (OWL)  [28] 
promoted  by  the  W3C  [27]  or  the  DAML-S  initiative,  supporting  semantic  mark-up  of  Web  services  [29]. 
These  approaches  support  the  creation  of  specialized  schemas,  to  represent  the  knowledge  within  a 
domain,  which  are  used  to  describe  various  resources  on  the  Web.  There  are  also  several  efforts  within  the 
semantic  web  research  community  that  build  on  these  concepts  to  provide  frameworks  for  meta-data 
driven  solutions.  Work  has  been  carried  out  to  support  RDF  based  metadata  in  JXTA,  including  query, 
replication,  mapping  and  annotation  services  [30].  Several  other  projects  have  constructed  dedicated  RDF 
databases  with  support  for  various  RDF  query  languages,  se  for  example  [31]  and  [32],  The  features  of 
these  approaches  are  diverse,  ranging  from  stand-alone  to  distributed  databases  or  P2P-style  systems. 


Figure  4.1.  Conceptual  view  of  a  proposed  framework  for  metadata  enabling  efficient  searching, 
matching  and  execution  within  the  NetSim  environment. 


4.3  Conclusions 

From  our  experiences  developing  the  DRMS  we  consider  the  lack  of  supporting  metadata  within  the 
NetSim  environment  is  of  major  concern.  The  support  for  meta-description  of  resources  within  JXTA  in 
general  is  relatively  weak,  mainly  key-word  based  searches  of  resource  advertisements.  We  envision  a 
layer  on-top  of  JXTA  supporting  more  complex  descriptions  of  resources  derived  from  a  shared  view.  The 
meta-data  layer  should  support  the  users  of  NetSim  in  simplifying  identification  and  matching  of  resources 
as  well  as  for  optimization  of  the  federation  execution.  We  consider  that  the  work  carried  out  within  the 
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semantic  web  community  is  of  great  interest  in  this  respect.  Concepts  from  this  area  could  be  applied  to 
model  knowledge  and  provide  extensive  meta-descriptions  of  resources  to  enable 
automatic/semiautomatic  localisation,  selection,  composition  and  execution  of  various  resources. 


5  SUMMARY  &  CONCLUSIONS 

At  the  Department  of  Systems  Modelling,  Swedish  Defence  Research  Agency,  ongoing  research  is 
targeting  the  role  of  network/web  based  technologies  in  M&S,  to  support  defence  communities  in  their 
work.  During  the  first  phase  of  this  research,  focus  has  been  on  efficient  resource  sharing  and  means  of 
computer  collaboration.  A  prototype,  named  NetSim,  has  been  implemented  to  investigate  and 
demonstrate  these  issues,  based  on  the  open-source  Peer-to-Peer  platform  JXTA.  The  NetSim  prototype 
allows  people  at  disperse  locations  to  collaborate  in  creating  various  HLA  simulations  in  a  component- 
based  manner.  Executions  of  the  assembled  simulations  utilize  idle  processing  capacity  of  desktops 
currently  connected  to  the  system.  As  the  NetSim  is  based  on  Peer-to-Peer  concepts,  and  not  dependant  on 
a  single  server  or  desktop  machine  within  the  network,  the  system  is  to  some  extent  more  robust  and  fault- 
tolerant  than  a  client-server  solution.  However  the  synchronization  of  collaboration  participants  is  partly 
based  on  centralized  control,  which  proved  non-efficient  and  non-scalable.  JXTA  was  at  the  time  of 
implementation  not  a  fully  mature  technology,  which  affected  the  overall  performance  of  NetSim  to  some 
extent.  For  example,  it  lacks  of  support  for  extensive  meta-descriptions  of  available  resources  on  the 
network.  However  it  should  be  pointed  out  that  JXTA  provides  a  rich  set  of  P2P  features,  suitable  for 
implementation  of  distributed  systems  such  as  NetSim.  Future  research  will  address  distributed  algorithms 
for  synchronisation  of  collaborative  work  and  a  more  flexible  and  extendable  approach  to  resource 
management. 
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ABSTRACT 

This  paper  presents  part  of  the  work  that  is  performed  internally  for  INTRACOM 
Defense  Department.  As  an  integral  part  of  this  work,  a  Battle  Management 
System  (INTRACOM  iBMS)  and  a  Computer  Generated  Forces  System 
(produced  by  INTRACOM  for  this  purpose)  are  linked  together.  As  an  example  of 
Lessons  learnt  from  past  experience  in  linking  M&S  and  C3I,  the  paper  discusses 
the  approach  that  was  used  to  connect  the  two  systems. 


Paper  presented  at  the  MSG-022/SY-003  Conference  on  “C3I  and  M&S  Interoperability  ”, 
held  in  Antalya,  Turkey,  9-10  October  2003,  and  published  in  RTO-MP-MSG-022. 
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BACKGROUND 


The  goal  of  the  performed  work  is  to  demonstrate  the  capability  to  couple  a 
Command  and  Control  system  together  with  a  CGF  system.  There  are  two 
perspectives  on  the  usefulness  of  this.  From  the  CGF  point  of  view,  the  use  of  a 
C3IS  as  an  interface  device,  optimizes  the  workload  of  the  instructors  and 
animators  of  tactical  environment.  It  also  reproduces  current  operational 
environment  especially  for  training  audience. 

From  the  C3IS  point  of  view,  interoperability  with  a  CGF  can  offer  new 
intelligent  services  in  war-gaming  and  planning,  reducing  the  need  for 
cumbersome  pre-battle  group-working  sessions. 

Simulation  systems  can  stimulate  the  C2  system  by  providing  data  that  simulates 
the  'real-world'.  This  information  now  appears  to  have  been  received  from  peer 
C2  systems.  In  this  way  a  simulated  COP  (Common  Operational  Picture)  is 
created  that  is  based  on  a  simulation  scenario.  Applications  of  this  technique  are: 
assessment  of  C2  systems  (performance,  user  interface  etc.),  assessment  of  C2 
operator  capabilities  or  training  of  C2  operators. 

The  simulation  can  provide  the  C2  operator  with  operational  decision  support  by 
executing  'what-if  scenarii.  Simulated  systems  can  be  'initialised'  from  the 
existing  COP  in  the  operational  C2  system  and  a  simulation  run  can  be  started 
based  on  this  information.  The  simulated  scenarios  supports  the  operator  in  his 
decision  making  process  (e.g.  mission  planning  or  assessment  of  alternative 
COA's). 

Simulations  can  assist  the  C2  staff  in  understanding  the  prepared  mission  plan 
(mission  rehearsal)  and  refining  the  plans  before  the  operation  is  executed. 
Commanders  will  be  able  to  identify  the  aspects  of  the  plan  that  will  be  crucial  for 
success  or  failure. 

Furthermore,  new  or  experimental  parts  for  an  existing  C2  system  can  be 
evaluated  before  purchase  or  even  before  full  development  by  replacing  an 
existing  component  of  the  C2  system  with  an  embedded  or  external  simulation. 
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Speech  recognition/voice  synthesis  techniques  has  been  taken  under 
investigation  as  alternatives  for  sending/receiving 

commands/reports/acknowledgements. 


C3I  System 


Figure  1  A  screenshot  of  INTRACOM  BMS 

The  most  fundamental  function  of  the  C3I  used  (namely  iBMS)  is  to  provide  the 
tactical  picture  to  the  commanders  (all  levels)  and  the  driver.  A  map  is  displayed, 
containing  dynamically  changing  geo-registered  information,  about  everything 
that  concerns  the  specific  user. 

Tactical  Situation  Update  utility,  allows  users  to  manually  refresh  the  tactical 
picture  of  the  entire  battalion,  through  a  number  of  mechanisms.  This  has  only  to 
do  with  information  regarding  the  enemy  forces. 

Logistics  functionality  is  the  function  providing  information  about  vehicle’s 
systems,  ammunition,  fuel  and  personnel  information.  This  function  is  also  valid 
for  echelon  commanders,  where  the  logistics  of  the  respected  echelon  can  be 
viewed. 
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C3I  also  provides  Tactical  planning.  An  echelon  commander  can  study  a  plan 
received  from  his  superior  officer  (next  level  in  command),  create  his\her  own 
plan  and  send  it  to  his  subordinates. 

Finally,  communication  facilities  allow  messaging  with  other  vehicles,  control  of 
transmission  media  etc. 

BMS  advantages 

Using  conventional  techniques,  i.e.  war-gaming  in  order  to  elaborate  the 
Operations  Order,  is  a  very  cumbersome  process.  Imagine  a  couple  of  vehicles 
moving  next  to  each  other  and  setting  a  tent  to  accommodate  all  the  involved 
parties.  They  form,  what  is  known  as  a  ‘cluster’.  In  that  cluster,  the  involved 
parties  draw  alternative  plans  on  thin  layers  of  film,  positioned  on  top  of  the  paper 
map. 

With  INTRACOM  C3I  (BMS)  we  get  a  completely  different  situation.  First  of  all, 
there  is  no  need  to  form  any  physical  clusters  any  more,  that  on  top  of  everything 
else  they  can  be  easy  targets  for  the  enemy.  Each  involved  party  can  take  part  in 
this  group-working  process  remotely,  through  the  use  of  the  BMS.  The  BMS 
offers  a  3-dimensional  view  of  the  map,  allowing  navigation  in  all  directions.  The 
user  can  select  ego-centric  and  exo-centric  views.  Of  course,  whatever  was 
possible  on  a  2-D  map  is  still  possible  to  do  with  the  3-D  view  of  the  map,  like 
measuring  distances,  determining  Line  Of  Sight  (LOS)  etc.  Each  individual  party 
involved  in  the  war-gaming  exercise,  places  his  units  and  he  can  move  them  or 
delete  them  to  elaborate  on  the  Operations  Order.  The  other  involved  parties  can 
then  see  the  move  of  the  first  player  and  respond  with  their  moves.  It  is 
something  like  playing  chess  or  bridge  on  the  internet.  Of  course,  all  this  can  be 
recorded  as  a  scenario  and  played  back  whenever  it  is  needed. 
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How  CGF  comes  into  the  game? 

However,  not  everything  can  be  dealt  efficiently  through  this  group-working 
process.  There  are  situations,  where  real  expert  play  is  required.  There  may  be  a 
need  for  additional  dimensions  of  the  situation  to  be  considered,  like  for  instance 
messages  to  be  exchanged  or  logistics  situations  during  the  game.  Then,  an 
opponent  like  the  computer  might  be  used  to  war-game  with.  This  time,  the 
metaphor  is  simply  like  playing  chess  against  the  computer. 

In  order  to  get  intelligent  behaviour  like  this,  the  use  of  a  Computer  Generated 
Forces  (CGF)  or  more  generally  speaking  of  a  simulation  federation,  was 
preferred.  How  to  do  that  however? 

There  are  various  challenges. 

First  of  all,  both  systems  (the  BMS  and  the  CGF)  should  run  on  the  same  single 
computer  of  a  vehicle.  This  is  not  as  easy  as  it  looks.  Keep  in  mind  that  it  is  very 
possible  to  deal  with  military  equipment  that  needs  to  meet  the  toughest 
environmental  standards.  Such  hardware  must  be  able  to  survive  in  temperature 
ranges  like  -40  C  to  +70  C,  making  us  think  about  what  happens  to  the  operator 
at  that  time.  It  should  come  to  no  surprise  then,  that  the  performance  of  such 
hardware  is  not  really  state-of-the-art  and  therefore,  hosting  a  BMS  and  a  CGF 
application  at  the  same  time  needs  at  least  some  attention. 

Secondly  it  is  clear  that  there  must  be  a  way  to  interface  the  two  systems.  As 
something  like  this  is  not  available  today,  it  was  obvious  that  an  interface  should 
be  developed.  But  before  thinking  about  the  right  interface  approach,  we  should 
consider  the  requirements  to  build  an  interface.  Luckily,  at  INTRACOM,  problems 
like  access  to  source  code  or  documentation  weren’t  met,  as  there  is  a  number  of 
small-scale  in-house  CGF  systems,  in  order  to  be  used  for  tests  together  with  the 
BMS.  Furthermore,  XML  packages  are  numerous  and  free  for  usage. 
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Introduction  to  XML  technology 

XML  is  a  meta-language  that  supports  the  customized  definition  of  the 
components  of  a  language  (syntax,  data  types,  vocabulary,  and  operators) 
needed  to  support  the  interchange  of  data  for  a  particular  application 
environment.  XML  provides  a  basis  for  the  development  of  data  transmission 
formats  that  are  transmitter  and  recipient  independent  and  that  can  be 
completely  self-describing  and  self-contained.  These  inherent  XML  capabilities 
permit  federates  to  be  added  to  a  federation  with  a  minimum  of  software 
development  and  with  high  confidence  that  information  exchanged  between 
federates  will  be  accurately  represented,  transmitted,  and  received  within  the 
federation. 

XML  permits  the  simulation  community  to  move  to  a  deeper  level  of  specification 
by  providing  data  definitions  and  formats  that  are  flexible,  independent,  and 
comprehensive. 

Extensible  Markup  Language  (XML)  can  make  its  contribution  to  distributed 
simulation  by  providing  an  interoperable  and  open  format  for  data  representation 
and  be  of  special  use  in  the  development  and  maintenance  of  computer¬ 
generated  actors  (CGAs). 

Each  application-specific  definition  is  contained  within  a  Document  Type 
Definition  (DTD).  The  DTD  describes  a  vocabulary  and  syntax  for  the  data 
(document)  to  be  transmitted.  XML  provides  a  basis  for  the  development  of  data 
transmission  formats  that  are  transmitter  and  recipient  independent  and  that  are 
completely  self-describing  and  self-contained. 
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Several  factors  indicate  that  XML  will  continue  to  grow  in  popularity  and  usage. 
First ,  XML  is  a  flexible  approach  to  formatting  documents.  The  XML  capability  to 
define  and  use  custom  tags  and  the  minimal  requirements  imposed  by  XML  on 
the  markup  language  being  designed  give  us  great  confidence  that  we  can 
express  the  transmission  format  robustly  within  the  boundaries  of  the  language. 
Second .  XML  is  widely  used  and  is  standardized;  therefore,  the  basic 
components  of  the  language  are  stable  and  well  understood. 

Third ,  XML  is  precise,  it  has  a  well  defined  set  of  rules  for  describing  a  document 
containing  the  markup  components  and  for  ordering  the  contents  of  a  document 
but  does  not  specify  semantics.  As  a  result,  XML  provides  the  basis  for 
developing  a  common  data  format  that  is  robust  in  the  face  of  data  corruption, 
self-describing  in  terms  of  tag  meaning,  and  extensible  to  accommodate 
unforeseen  data  requirements. 

Fourth ,  because  XML  supports  the  definition  of  custom  tag-sets  and  custom 
document  structures  that  are  completely  contained  within  the  document,  an  XML- 
based  specification  for  CGA  state  can  be  automatically  searched  and 
categorized  by  computer  programs  instead  of  manually. 

Fifth ,  XML  provides  interoperability  between  different  platforms. 

Finally ,  XML  supports  the  creation  and  use  of  multi-part,  distributed  documents 
and  supports  interchange  of  data  between  applications. 
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Approach  followed 


C3  messages 

nr 

i 

CGF  Messages 

produced  by  C3 

i 

produced  by 

Shared  File  System 

for  CGF. 

i 

i 

CGF  for  C3. 

C3  simulation  liters  age 

C£E^esponse 

CGF  XML  Interfac  e  ^ - ► 

CGF  System  ^ 

Figure  2  XML  Approach  for  interfacing  C2  world  and  CGF  world 


Technically  speaking,  the  purpose  is  to  connect  a  C3I  operator  to  a  constructive 
simulation.  Both  systems  agree  on  common  XML  formats  that  should  be 
“exchanged”  (each  system  has  to  understand  what  the  other  has  sent)  and  on 
common  content  (vocabulary).  Vocabulary  means  the  possible  types  of 
messages  that  are  going  to  be  used  in  a  scenario.  Messages  like  ‘Move  order’, 
‘Logistics  report’,  ‘Situation  Report  request’,  ‘Order  Of  Battle’  etc.  are  agreed 
upon.  The  set  of  messages  handled  by  a  CGF  is  of  course,  only  a  subset  of 
those  of  a  BMS,  as  they  do  not  include  free  text  messages. 

The  data  flow  between  the  C3IS  and  the  CGF  relies  on  XML  technology.  The 
components  addressing  this  interface  share  a  common  directory  (using  File 
System,  eventually  mounted  in  case  of  different  machines),  writing  and/or 
reading  XML  files  that  depict  messages  that  are  being  exchanged. 
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A  synchronization-pool  mechanism  (see  Figure  2)  is  used.  Both  systems  agree  on 
the  directories  that  they  shall  be  shared. 

o  One  directory  (let’s  call  it  C3_dir)  is  used  by  C3I  system  to  write  its 
commands.  CGF  reads  from  this  directory, 
o  One  directory  (let’s  call  it  CGF_dir)  is  used  by  CGF  system  to  write  its 
reports  to  C3I.  C3I  reads  from  this  directory. 

A  semaphore  file  is  used.  When  an  application  (C3I  or  CGF)  wants  to  read/write 
from/to  a  directory  it  first  checks  for  a  semaphore.  If  the  semaphore  is  there,  then 
the  application  removes  the  semaphore,  does  its  job  (writes  new  files/reads  files) 
and  then  puts  the  semaphore  back  to  make  the  directory  usable  by  the  other 
application. 


The  main  advantage  of  this  solution  is  to  ensure  generic  and  device-independent 
simulation  messages  in  order  to  support  information  coming  from  and  going  to 
the  two  interfaces  that  were  used;  the  command  and  control  system  and  a  vocal 
interface.  The  two  interfaces  (from  the  CGF  point  of  view)  are  independent  one 
from  another  and  each  remains  functional  without  the  other.  This  allows  to  easily 
build  scalable  and  multi-level  systems  and  to  deploy  them  depending  on  the 
training  needs.  Both  interfaces  define  some  requirements  on  this  CGF  in  order  to 
ensure  consistency  between  requirements  addressing  CGF.  As  the  intermediate 
XML  layer  controls  the  data  entities  and  ORBAT  of  all  involved  sides,  it  is 
possible  that  the  C3IS  initiates  the  loading  of  those  data.  At  the  application  level, 
that  means  that  the  C3IS  is  capable  of  playing  what-if  scenarii  without  the  need 
for  war-gaming  sessions  involving  a  number  of  human  operators. 


Types  of  exchanged  messages 

Here  is  a  list  with  the  type  of  messages  that  are  exchanged  during  interaction 
between  the  two  systems: 

•  C3I  to  CGF 
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o  C3I  can  request  a  “Logistics  Report”  from  unit  or  group  of  units, 
o  C3I  can  send  a  “Move”  order  to  a  group  of  units 
(company/squadron/platoon/etc.)  with  information  about  waypoints 
that  must  be  followed,  type  of  formation  and  speed  they  should 
keep. 

•  CGF  to  C3I 

o  CGF  sends  an  “Acknowledgement  message”  for  each  command  it 
receives  from  C3I. 

o  CGF  sends  a  “Logistics  Report”  for  the  unit  or  group  of  units  from 
which  C3I  requested  information, 
o  CGF  may  send  “Enemy  positions  report”. 

o  CGF  may  send  its  ORBAT  (OR  of  BATIIe),  so  that  C3I  to  be  able  to 
update  the  units  representation  on  its  map. 
o  CGF  may  send  “Under  Attack”  for  each  of  the  units  that  are  under 
attack  by  enemy  forces. 


C3IS  enrichment 

Utilization  of  Voice  Synthesis/Recognition  technology  can  enrich  the  C3I  system 

-  A  Voice  Synthesis  component  could  produce  voice  that 
corresponds  to  a  received  message.  This  would  make  the 
interaction  between  C3I-CGF  look  closer  to  reality.  For  example, 
when  C3I  receives  an  “Under  Attack”  message  from  CGF  a  voice 
could  be  produced  like  “Under  Attack  from  1112  unit”. 

-  A  Voice  Recognition  component  would  be  useful  as  alternative 
way  of  sending  a  command.  E.g.  the  C3I  commander  could  send  a 
request  for  logistics  report  either  using  the  graphical  interface  of 
C3I  or  through  his/her  voice  (using  the  vocal  part  of  C3I). 
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CONCLUSION 

XML  was  successfully  used  on  a  C3I  to  assist  the  user  in  his  decision  making 
process  and  in  understanding  and  refining  mission  plans. 

Building  such  an  interface  using  XML,  a  common  format  and  content  is  required, 
as  well  as  a  way  of  synchronising  the  two  systems. 

The  main  advantage  of  this  solution  is  that  it  ensures  generic  and  device¬ 
independent  simulation  messages  in  order  to  support  information  coming  from 
and  going  to  the  two  interfaces  that  are  used;  the  Command  and  Control  system 
and  the  Voice  Recognizer.  The  two  interfaces  (from  the  CGF  point  of  view)  are 
independent  one  from  another  and  each  remains  functional  without  the  other. 
This  allows  to  easily  build  scalable  and  multi-level  systems  and  to  deploy  them 
depending  on  the  training  needs.  Both  interfaces  define  some  requirements  on 
this  CGF  in  order  to  ensure  consistency  between  requirements  addressing  CGF. 
As  the  intermediate  XML  layer  controls  the  data  entities  and  ORBAT  of  all 
involved  sides,  it  is  possible  that  the  C3I  initiates  the  loading  of  those  data.  At  the 
application  level,  that  means  that  the  C3I  is  capable  of  playing  what-if  scenarii 
without  the  need  for  war-gaming  sessions  involving  a  number  of  human 
operators. 

The  approach  has  proved  to  be  fruitful  as  the  communication  between  the  C3IS 
and  the  CGF  is  successful  using  both  the  messaging  and  vocal  interface. 

The  approach  is  proven  definitely  flexible  and  relatively  easy  to  achieve. 

However,  it  is  an  interface  devoted  to  the  specific  pair  of  systems  and  cannot  be 
reused  for  any  selection  of  systems  (namely  the  mechanism  and  its  working 
parts  are  not  like  a  template  that  can  be  used  between  a  different  C3I  and  CGF 
system). 
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Abbreviations: 


BMS 

Battle  Management  System 

C3I/S 

Command  Control  and  Communication 

Information  /  System 

CGA 

Computer  Generated  Actors 

CGF 

Computer  Generated  Forces 

COA 

Courses  Of  Action 

COP 

Common  Operational  Picture 

LOS 

Line  Of  Sight 

M&S 

Modeling  and  Simulation 
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NATO  Topical  Group  1 


This  paper  has  been  prepared  on  behalf  of  NATO  Topical  Group  1  (TG/1)  at  the  direction  of  the  UK 
Ministry  of  Defence  Future  Integrated  Soldier  Technology  (FIST)  Integrated  Project  Team  (IPT).  TG/1  is 
a  Level  2  Group  and  is  concerned  with  soldier  system  interoperability.  The  Group  is  open  to  and  attended 
by  Partners.  Australia  has  been  granted  observer  status.  The  TG/1  objectives  set  by  the  NATO  Armaments 
Advisory  Group  (NAAG)  are  as  follows: 

a.  to  develop  STANAGs  in  5  focus  areas; 

b.  to  foster  information  exchange  on  soldier  systems; 

c.  to  broaden  and  deepen  interaction  between  groups  in  the  NAAG. 

Develop  STANAG  in  5  focus  areas:  These  focus  areas  are  as  follows: 

a.  Power  -  a  STANAG  is  currently  being  finalised,  addressing  dismounted  soldier  electrical  supply 
systems. 

b.  Architecture  -  focusing  on  electrical  interface  and  data  protocols. 

c.  Clothing,  equipment  &  protection  -  seeking  to  establish  current  standardisation  work  already 
underway  within  NAAG. 

d.  Weapons  -  a  newly  defined  area  of  work. 

e.  C4I  -  concentrating  on  the  exchange  of  low  level  tactical  information  exchange. 

Foster  information  exchange  on  soldier  systems:  TG/1  brings  together  the  nations  with  major 
programmes  and  those  seeking  to  select  solutions,  or  elements  of  the  solution,  from  the  ‘major  players’. 
Standardisation  increases  the  potential  to  achieve  this  intent. 

Broaden  and  deepen  interaction  between  groups  in  the  NAAG:  TG/l's  role  is  to  ensure  that  work 
underway  elsewhere  in  the  NATO  is  focussed  towards  meeting  the  needs  of  the  dismounted  soldier.  This 
implies  the  need  to  link  with  other  relevant  NATO  Groups,  where  issues  such  as  vehicle  system  interfaces 
and  combat  identification  are  being  addressed. 

TG/1  evolved  from  the  former  LG3  WGE3  and  has  a  mandate  to  operate  until  Autumn  2004.  Work  under 
LG3  WGE3  included  a  task  to  provide  guidance  to  the  modelling  and  simulation  community  (principally 
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LG3  WGE4).  As  a  predominantly  User-based  group  with  technical  support,  it  was  considered  important  to 
provide  guidance  to  the  modelling  and  simulation  community  to  ensure  that  outputs  were  expressed  in 
terms  readily  understood  by  the  military.  That  work  proceeded  with  a  systems  analysis  of  dismounted 
tasks  and  generated  an  effectiveness  measurement  framework  with  an  emphasis  on  defining  Measures  of 
Effectiveness  (MoEs)  at  the  mission  level.  The  focus  was  to  ensure  that  the  modelling  and  simulation 
community  could  focus  its  work  and  produce  outputs  to  which  TG/1  could  relate.  The  work  has  been 
termed  ‘NATO  measurement  framework’ . 

As  part  of  this  work,  TG/1  attempted  to  better  understand  C4I  MoEs.  The  next  section  overviews  the 
systems  analysis  conducted  to  identify  MoEs  associated  with  company  level  and  below,  before  exploring 
our  C4I-related  analysis.  The  development  of  a  STANAG  to  define  data  formats  for  low-level  tactical  data 
exchange  is  then  described. 

Low  level  mission  analysis  -  overview 

Analysis  has  been  undertaken  of  dismounted  operations,  typically  at  Company  level  and  below.  Missions 
have  been  decomposed  into  component  vignettes.  Listed  below  are  some  of  the  component  vignettes  that 
have  been  identified  for  a  mission  ‘to  attack  and  hold  an  enemy  position’ : 

a.  planning  and  preparation; 

b.  close  target  recce; 

c.  advance; 

d.  attack; 

e.  re-org; 

f.  defence; 

g.  re-org. 

Collective  Measures  of  Effectiveness  (CMoEs)  have  been  defined  for  each  of  these  vignettes.  As  and 
example,  the  close  target  recce  vignette  could  have  the  following  CMoEs: 

a.  detection  avoidance  (Y/N); 

b.  consumables  employed; 

c.  time  taken  (as  in  orders?); 

d.  casualties; 

e.  quality  of  information  obtained  (subjective); 

f.  physical  and  mental  sate  of  soldiers  employed  (i.e.  their  ability  to  continue  operations). 

At  the  mission  level,  the  CMoEs  would  be  selected  from  those  defined  for  the  vignettes  in  the  context  of 
the  orders  set.  Some  of  the  vignette  level  CMoEs  would  become  unimportant  at  the  mission  level  and 
would  not  be  employed  (e.g.  detection  avoidance  during  close  target  recce).  For  the  example  mission, 
these  could  be: 

a.  own  casualties; 

b.  other  soldier's  condition; 

c.  consumables; 

d.  achieving  key  event  timings  specified  in  orders. 

The  relative  importance  of  CMoEs  will  vary  according  to  the  mission;  e.g.  the  situation  may  determine 
that  holding  an  objective  for  the  specified  time  is  more  important  than  casualties  suffered. 

The  measurement  framework  also  indicates  how  the  relationship  between  the  soldier  and  his  equipment 
within  the  physical  and  organisation  environments  contributre  to  providing  a  level  of  capability  to 


RTO-MP-MSG-022:  C3I  &  Modelling  and  Simulation  Interoperability 


12-2 


undertke  a  task.  Actual  equipment  Measures  of  Performance  are  thus  modified  to  bring  a  certain  level  of 
capability  with  which  to  undertake  a  task.  This  is  shown  in  Figure  1.  T  , 

Level 


la 


lb 


2a 


2b 


Figure  1:  Measurement  framework  levels 

Low  level  mission  analysis  -  C4I  aspects 

The  NATO  measurement  framework  has  established  effectiveness  principles  relating  to  command  and 
control  (C2).  If  C4I  equipment  is  to  be  evaluated,  perhaps  during  field  trials,  then  a  data  collection 
approach  must  be  defined.  Analysis  has  identified  the  following  general  C2-related  capabilities: 

a.  the  ability  to  receive  and  pass  on  orders  prior  to  the  start  of  the  mission  ( orders  pre-mission); 

b.  the  ability  to  navigate  ( navigation ); 
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c.  the  ability  to  achieve  a  level  of  direct  situational  awareness  consistent  with  the  needs  of  the  mission 
(direct  situational  awareness); 

d.  the  ability  to  achieve  a  level  of  indirect  situational  awareness  consistent  with  the  needs  of  the 
mission  (indirect  situational  awareness); 

e.  the  ability  to  provide  an  adequate  post  mission  debrief  (debrief); 

f.  the  ability  to  operate  covertly  (detection  avoidance); 

g.  the  ability  to  adapt  the  plan  as  a  result  of  changing  circumstances  that  develop  after  the  mission  has 
commenced  (‘command  agility’); 

h.  the  ability  to  achieve  key  event  timings  (key  event  timings); 

i.  the  ability  to  re-organise  the  soldiers  after  the  completion  of  the  mission  in  a  timely  manner 
(reorganisation  time). 

Command  agility 

For  all  but  one  of  the  above  capabilities,  the  MoEs  associated  can  be  defined  with  relative  ease.  Often,  but 
not  exclusively,  the  CMoE  associated  with  C4I  is  time.  Flowever,  C4I  could  actually  make  a  mission 
longer,  if  a  more  covert  route  was  established  that  allowed  an  enemy  position  to  be  taken  by  surprise. 
Flere,  the  effectiveness  of  the  C4I  would  derive  from  a  reduction  of  own  casualties. 

The  most  challenging  C4I  capability  to  analyse  was  point  g,  " the  ability  to  adapt  the  plan  as  a  result  of 
changing  circumstances  that  develop  after  the  mission  has  commenced" .  TG/1  have  termed  this  ‘C2 
agility’.  If  a  mission  proceeded  according  to  the  original  plan,  it  could  be  argued  the  actual  conduct  of  the 
mission  could  have  been  completed  without  the  commander.  However,  it  is  when  unforeseen,  or 
unpredicted,  changes  to  the  mission  have  to  be  managed  that  the  commander,  supported  by  C4I,  must 
intervene.  Qualitative  assessment  of  the  performance  of  C2  during  such  situations  can  be  assessed,  using  a 
structure  that  seeks  to  analyse  the  C2  process  when  managing  the  situation. 

Command  agility  analysis  is  conducted  by  applying  the  following  questions  to  events  that  required 
commander  intervention: 

a.  Did  the  mission  go  according  to  the  original  plan? 

b.  If  not,  what  caused  the  need  to  deviate  from  the  plan? 

c.  Was  this  change  communicated  efficiently  to  those  concerned?  Was  the  change  implemented  as 
intended? 

d.  Was  the  commander’s  situational  awareness  adequate  when  the  change  was  defined? 

e.  If  not,  what  information  did  the  commander  need  and  what  would  have  been  the  best  way  of 
accessing  this  information? 

f.  Could  anything  be  done  to  improve  the  way  the  change  was  implemented? 

g.  Did  the  change,  as  implemented,  have  a  critical  impact  on  the  outcome? 

h.  Are  there  any  other  material  factors  that  affected  C2  flexibility? 
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After  action  reviews  of  UK  C4I  field  trials,  provided  responses  to  the  above  analysis,  from  each 
commander.  The  technique  has  been  used  to  establish  effectiveness,  both  with  current  C4I  and  then  with 
enhanced  systems.  Often  it  is  possible  to  demonstrate  that,  when  the  re-direction  was  inadequately 
implemented,  it  could  be  linked  either  with  the  failure  of  the  mission  or  reduced  collective  effectiveness. 
Although  a  subjective  process,  it  does  provide  a  basis  for  analysis  of  the  effectiveness  of  C4I. 

Analysis  subsequently  concluded  that,  when  assessing  the  outcome  of  a  mission,  it  was  necessary  to 
include  a  factor  that  related  to  the  degree  of  difficulty  imposed  on  the  commander  by  external  events  that 
occurred  during  the  conduct  of  that  mission.  Only  in  this  way  can  C41  be  accurately  addressed. 

The  CMoE  framework  has  been  used  extensively  in  national  trials  as  a  qualitative/quantitative  mechanism 
to  assess  performance  of  capability.  The  work  has  been  published  by  NAAG  [1]  but  requires  updating, 
following  experience  gained  in  its  use  on  field  trials. 

Requirement  for  low-level  tactical  data  exchange 

This  section  of  the  paper  addresses  the  TG/1  C4I  team’s  work  on  production  of  a  STANAG  relating  to 
data  formats  for  achieving  low-level  tactical  interoperability. 

One  might  ask  where  the  requirement  is  for  sharing  information  at  such  a  low  level?  There  is  no  NATO 
requirement  at  present  but  the  TG/1  C4I  team  is  tasked  with  exploring  the  ‘art  of  the  possible’.  It  is  then 
down  to  NATO  to  decide  whether  the  capabilities  offered  will  be  employed.  However,  there  is,  at  present, 
a  high  degree  of  force  mixing  within  NATO  operations.  Dutch  platoons  operate  within  UK  companies 
during  peace  keeping.  Furthermore,  the  sharing  of  tactical  information  across  force  boundaries  will 
provide  an  increase  in  situational  awareness.  This  may  well  contribute  to  a  reduction  in  the  occurrence  of 
potentially  fratricidal  situations.  In  exploring  the  art  of  the  possible,  TG/1  is  establishing  other  associated 
challenges  that  must  be  met,  particularly  those  related  to  security  and  radio  bearers.  These  are  listed 
below.  There  are  other  challenges  related  to  NATO  itself  that  are  also  being  addressed.  The  key  one  is 
ensuring  that  TG/l's  work  does  not  duplicate  work  already  being  undertaken  elsewhere  within  the  NATO 
system.  TG/1  aims  to  ensure  that  the  data  model  that  is  being  developed  is  correctly  placed  within  the 
overall  NATO  data  model.  This  is  very  complex  and  work  has  only  recently  commenced. 

Approach  taken  to  development  of  a  STANAG  for  low-level  tactical  data 

interoperability 

The  tactical  information  interoperability  STANAG  is  being  developed  in  parallel  with  an  experimental 
and  demonstration  programme.  The  scope  of  tactical  data  exchange  would  include: 

a.  positional  data; 

b.  force  boundaries; 

c.  positions  of  key  features  e.g.  minefields; 

d.  text  information; 

e.  lines  of  departure; 

f.  APP6a  symbols. 

Relevant  tactical  data  needs  to  have  been  identified.  Many  of  these  are  addressed  in  APP6a.  The 
possibility  of  updating  APP6a  to  include  further  types  is  being  explored.  TG/1  has  listed  all  the  symbols 
and  related  information  that  are  of  use  to  enable  awareness  sharing  at  the  lower  level.  Many  of  these  are 
covered  by  APP6a  but  some  are  not.  These  TG/1  is  seeking  to  have  included. 

TG/l's  approach  has  been  to  generate  what  can  be  termed  ‘the  NATO  data  library’.  This  is  a  definition  of 
how,  in  a  country-independent  format,  tactical  objects  and  their  attributes  should  be  described. 
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Example  information  includes: 


a.  co-ordinate  (latitude/longitude  as  floating  point,  based  on  WGS84  datum  grid). 

b.  object  identity  size  (integer). 

c.  object  identity  (e.g.  callsign  as  text). 

d.  object  nation  (e.g.  UK  as  fixed  text  field  of  2  characters). 

e.  date/time  (e.g.  DDMMYYhhmmss  as  fixed  text  field  of  12  characters). 

The  STANAG  does  not  intend  to  specify  how  an  individual  country  will  actually  display  an  item  of 
tactical  data,  if  it  does  not  wish  to  use  it  or  finds  that  APP6a  symbols  are  not  suited  to  small  scale 
electronic  map  displays.  Where  symbols  have  an  APP6a  identity  number,  that  identity  number  defines  the 
object  in  TG/l's  approach  and  hence  the  reason  an  update  to  APP6a  is  needed. 

Having  defined  how  information  should  be  described,  it  was  then  necessary  to  seek  a  format  to  send  the 
information  between  one  national  system  and  another.  This  data  definition  is  described  using  Backus-Naur 
Form  (BNF).  The  definition,  together  with  the  object/attribute  list,  provides  the  basis  for  the  creation  of  an 
appropriate  interchange  data  reader  and  writer.  This  is  what  TG/1  has  termed  in  the  NATO  library  and  this 
is  a  country-neutral  definition. 

For  the  purpose  of  the  experimental  programme,  a  NATO  library  code  has  been  generated  to  suit  three 
different  operating  systems  used  in  the  experimental  and  demonstration  programme  (WINDOWS  98/NT, 
WINDOWS  CE  and  Linux). 

TG/1  is  linked  with  the  International  Collaborative  Opportunities  Group  (ICOG),  to  further  the 
achievement  of  low-level  tactical  data  interoperability.  The  ICOG  nations  are  UK,  US,  Germany,  France 
and  Italy,  but  all  NATO  nations  and  Partners  are  invited  to  joint  TG/1  /  ICOG  experimental  workshops. 
The  NATO  nations  actively  participating  in  the  experimental  and  demonstration  programme  are  Canada, 
France,  Germany,  Norway,  UK  and  the  US  (Army  and  Marines).  Some  nations  employ  prototype  systems, 
whilst  others  participate  with  research  equipment.  All  use  different  map  applications.  Each  nation  has 
written  a  file  that  allows  it  to  read  from  and  write  to  the  neutral  format. 

Experiments  are  conducted  inside,  with  systems  co-located  around  a  table.  The  mechanism  for  exchange 
between  national  systems  (for  experimental  and  demonstration  purposes)  has  been  via  WLAN  802.11b. 
The  tactical  information  for  exchange  is  generated  within  a  map  application  layer  (typically  about  1Kb  file 
size).  The  information  therein  is  then  written  to  the  NATO  neutral  format  and  sent  as  an  attachment  to  an 
e-mail,  addressed  to  one  or  more  nations  participating  in  the  experiment.  On  receipt,  the  receiving  national 
system  automatically  opens  the  attachment,  feeds  the  neutrally  formatted  information  into  its  conversion 
program  and  then  displays  the  received  information  correctly  geo-referenced. 

Progress  in  experimental  programme/planned  activites 


Successful  data  exchange  has  been  achieved  between  UK  research  C4I  sets  and  C4I  equipment  from 
Canada,  Norway  and  France  and  the  US.  The  level  of  tactical  information  is  superficial  at  this  stage,  but  it 
is  sufficient  to  establish  and  check  principles.  In  2002,  using  an  earlier  version  of  the  library,  the  UK  and 
Canada  exchanged  information  by  way  of  floppy  disk.  Figure  2  provides  a  typical  example  of  successful 
exchange  between  the  UK  and  Norway,  both  with  different  operating  systems  and  map  applications.  The 
Norwegian  system  (left)  displays  UK  tactical  information  and  the  UK  system  (right)  displays  both  UK 
tactical  data  and  that  received  from  Norway.  At  a  joint  ICOG  /  TG/1  C4I  meeting  in  Oslo  in  June  2003, 
exchange  over  WLAN  was,  to  some  degree,  achieved  between  Norway,  France  and  the  US.  Further 
experimental  workshops  are  planned  between  writing  and  delivery  of  this  paper.  The  TG/1  C4I  team  will 
provide  a  demonstration  of  tactical  information  interoperability  to  the  full  TG/1  meeting  to  be  held  in 
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Rome  (22  October  2003)  and  to  the  NAAG  in  Autumn  2004.  Other  nations,  including  a  Partner  nation,  are 
beginning  to  become  active  in  the  experimental  programme.  It  is  anticipated  that  the  number  of  nations 
participating  in  the  NAAG  demonstration  may  reach  ten.  The  experimental/demonstration  programme  has 
assisted  greatly  in  de-risking  the  STANAG,  scheduled  for  publication  in  Autumn  2004. 

Challenges  to  achieving  low  level  tactical  data  exchange 


Clearly,  establishing  the  formats  for  data  exchange  is  a  relatively  straightforward  task;  actually  achieving 
the  tactical  interoperability  on  the  ground  may  not  be  so.  Tactical  exchange,  in  any  ‘interoperable  session’, 
is  likely  to  be  limited  to  just  two  nations,  but  this  need  not  be  the  case.  The  challenges  that  the  combined 
group  is  addressing  include  the  following: 

a.  communications  bearer; 

b.  security; 

c.  encryption; 

d.  unauthorised  use  of  systems; 

e.  information  conflict; 

f.  situating  TGl's  data  model  within  the  overall  NAAG  data  model; 

g.  STANAG  maintenance. 

Communications  bearer:  With  software  programmable  radios  universally  employed,  exchange  is, 
theoretically,  ‘easily’  possible.  The  C4I  team  has  been  exploring  the  loaning  of  a  radio  to  an  adjacent  force 
and  has  ensured  the  necessary  interface  information  is  embedded  in  TG/1  architecture  STANAG  should 
this  the  approach  selected. 


Figure  2:  Norway  (left)  -  UK  (right)  tac  data  exchange  using  WLAN  March  2003 
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Alternatively,  the  exchange  could,  in  theory,  be  achieved  today  using  a  WLAN-based  solution,  if 
range/bandwidth  performance  become  adequate. 

Security:  Here  the  issues  associated  with  the  connection  of  potentially  secure  systems  have  addressed. 
There  are  the  associated  problems  of  virus  control,  the  potential  to  ‘snoop’  on  the  other  system. 

Encryption:  Encryption  can  be  applied  but  this  will,  inevitably,  increase  the  data  traffic,  with  the  penalty 
of  added  bandwidth  being  required.  Some  nations  may  consider  that  low-level  data  that  will  become  ‘time 
expired’  quickly  and  this  could  be  sent  with  minimal  or  no  encryption  over  radios  with  relatively  short 
ranges. 

Unauthorised  use  of  systems:  TG/1  is  addressing  issues  such  as  system  integrity.  This  includes  problems 
associated  with  the  unauthorised  use  of  captured  radios;  an  enemy  could  not  gain  tactical  advantage  from 
knowledge  of  "blue"  positions  and  intentions  but  also  has  the  potential  to  overload  networks. 

Information  conflict:  Clearly  the  potential  exists  to  duplicate  information  being  passed  between  forces  at 
a  higher  level.  If  TG/l's  system  were  implemented,  it  could  be  that  that  information  received  across  the 
force  boundary  should  not  passed  up  the  command  chain  automatically. 

Situating  the  TG/1  data  model  within  the  overall  NATO  data  model:  A  significant  challenge  that  is 
being  addressed  is  ‘why  is  another  data  model  needed?’  The  potential  exists  to  use,  for  example,  the 
Multinational  Interoperability  Programme  (MIP)  data  model  or,  possibly,  a  derivative  thereof,  or  an 
alternative  NATO  data  model.  The  TG/1  /  ICOG  C4I  team  is  establishing  whether  any  fundamental 
differences  exist  between  TG/l's  proposed  model  and  those  that  already  exist.  There  is  a  concern  that,  as 
‘soldier  carried’  systems  have  limited  computing  power,  driven  by  the  weight/power  issue  and  bandwidth 
limitations  exist  with  tactical  radios,  a  specifically  tailored  data  model  may  be  necessary.  This  need  must 
be  demonstrated. 

STANAG  maintenance:  Given  that  computing  and  operating  systems  may  be  frequently  updated, 
consideration  has  been  given  to  the  use  of  a  programming  language  such  as  XML  as  these  are  operating 
system  independent.  XML  may  be  the  way  to  go,  provided  it  does  not  create  an  unnecessarily  high  data- 
passing  requirement.  If  XML  is  selected,  there  is  the  potential  to  use  the  NATO  web  site  for  configuration 
control.  A  further  issue  is  whether  there  should  be  an  XML  version,  tailored  to  TG/l's  needs. 

The  future 

There  are  ‘Strawmen  approaches’  for  the  above,  but  these  are  in  an  early  stage  of  definition.  If  the  NAAG, 
following  the  demostration  of  TG/l's  experimental  work,  determines  that  it  is  of  relevance,  follow-on 
effort  would  begin  to  address  the  aformentioned  challenges. 

Clearly,  the  benefit  of  TG/l's  work  will,  inevitably,  depend  on  national  policy.  This  may  be  determined  bi¬ 
laterally,  on  each  coalition  operation.  It  would  also  require  consideration  of  the  level  at  which  tactical 
information  interoperability  is  achieved;  again,  this  would  be  a  bi-lateral  decision,  which  might  be  at  the 
platoon  commander  level. 

Any  NATO  movement  towards  a  greater  degree  of  force  mixing,  particularly  during  peacekeeping 
operations,  may  also  underpin  the  need  for  the  STANAG.  Policy  decisions  are  awaited  with  interest! 

The  experimental  programme  has  been  genuine  international  collaboration,  as  engineers  of  many  nations 
are  working  together.  There  has  been  a  signicant  information  flow  between  national  programmes  meeting 
one  of  the  other  key  objectives  set  by  NAAG  for  Topical  Group  1. 
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Abstract 

Multinational  coalitions  are  the  standard  for  land  forces  in  the  full  spectrum  of  land  war  fighting  from 
operations  other  than  war  to  armed  conflict.  Recent  military’  events  have  underlined  the  necessity  of 
interaction  among  the  peacekeeping  participants,  most  notably  through  the  channels  of  liaison. 
Interoperability  of  the  nationals  systems,  Command  and  Control  (C2)  data  information  exchange,  reliability > 
of  the  systems  are  chiefly  the  goals  for  future  National  Military >  Architecture. 

The  goal  of  this  paper  is  to  describe  the  opportunity  offered  to  MEADS  by  the  adoption  of  CORBA  (Common 
Object  Request  Broker  Architecture).  The  intent  is  not  to  describe  the  current  MEADS  architecture  neither 
its  future  planned  development;  it  simply  shows,  using  MEADS  as  an  example,  a  possible  implementation 
able  to  underline  the  advantages  that  such  architecture  could  provide  to  a  complex  Air  Defence  system. 


ORGANIZATION 


1.  SUMMARY 

The  paper  provides  a  brief  introduction  on  MEADS  system,  reviews  mainly  the  general  concepts  of  CORBA 
Architecture  describing  the  technical  details  that  realize  the  interoperability  in  a  heterogeneous 
communication  environment,  suggesting  a  possible  implementation  of  CORBA  Architecture  to  an  Air 
Defence  System  such  as  MEADS  underlining  the  advantages  of  the  approach  adopted. 

The  last  part  of  the  paper  describes  which  kind  of  analysis  has  been  adopted  to  estimate  the  CORBA  data 
load  budget  that  characterize  the  Architecture  of  the  system  taken  as  an  example. 

2.  MEADS  (Medium  Extended  Air  Defence  System) 

The  MEADS  System  Architecture  consists  of  hardware  and  software  elements  configured  in  a  TDMA 
communications  networks  that  efficiently  accomplish  real-time  Command  and  Control  of  total  systems 
operations.  Figure  1  shows  the  MEADS  System  Concept. 

In  order  to  realize  Interoperability  and  Plug  and  Fight  concepts  MEADS  System  will  operate  in  a  netted  and 
distributed  mode.  Netted  architectures  are  seamless  and  self-healing  based  on  the  availability  and  reliability 

Paper  presented  at  the  MSG-022/SY-003  Conference  on  "C3I  and  M&S  Interoperability  ”, 
held  in  Antalya,  Turkey,  9-10  October  2003,  and  published  in  RTO-MP-MSG-022. 
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of  organic  and  supporting  communications. 

Distributed  operations  are  characterized  by  physical  dispersion  of  engagement  functions  or  groups  of 
functions  on  the  battlefield,  wherein  data  exchanges  via  broadcast  or  flood/multi-route  patterns  may  take 
place  over  extended  distances. 

The  combination  of  netted  and  distributed  characteristics  reduces  the  likelihood  of  a  single  point  failure, 
which  disrupts  tactical  operations. 


EXTERNAL  SOURCES 


•  1  SR 

•2  MFCR 

•  2  TOC  &  2  ASV 

•  6  Launchers 

•  3  Reloaders 

•  108  Missiles 

•  50  Personnel  w/o  Support 


•  Solid  motor  propulsion 

•  Two-Pulse  Motor 

•  Active  RF  Seeker 

•  Hit-T  o-Kill 


•  12  Missiles  per  Launcher 

•  12  Missiles  per  Reloader 

•  Pallet  Handling  System 

•  Partial  Reload  of  any  Number 


Multi-Function  Fire 
Control  Radar 


Pulse  Doppler  Multifunction 
Phased  Array 
X  Band 

360°  Coverage 

Generator 

Transformer 

Missile  Uplink  /  Downlink 


PCU  (1) 


Figure  1:  MEADS  System  Concept 


3.  CORBA  ARCHITECTURE  AND  INTEROPERABILITY 


CORBA  (Common  Object  Request  Broker  Architecture),  OMG’s  open,  vendor-independent  architecture  and 
infrastructure,  specifies  a  system  which  provides  interoperability  between  objects  in  a  heterogeneous, 
distributed  environment  and  in  a  way  transparent  to  the  programmer. 

The  central  component  of  CORBA  is  the  Object  Request  Broker  (ORB).  It  encompasses  the  entire 
communication  infrastructure  necessary  to  identify  and  locate  objects,  handle  connection  management  and 
deliver  data.  In  general,  the  ORB  is  not  required  to  be  a  single  component;  it  is  simply  defined  by  its 
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interfaces.  The  ORB  Core  is  the  most  crucial  part  of  the  Object  Request  Broker;  it  is  responsible  for 
communication  of  application  requests. 

CORBA  applications  are  composed  of  objects.  An  object  is  an  identifiable,  fully  encapsulated  entity  that 
provides  one  or  more  services  that  can  be  requested  by  a  client  by  means  of  a  well-defined  interface  (see 
Figure  2)  defined  in  IDL  (Interface  Definition  Language). 

An  interface  is  a  description  of  a  set  of  possible  operations  that  a  client  may  request  of  an  object,  through  that 
interface.  It  provides  a  syntactic  description  of  how  a  service  provided  by  an  object  supporting  this  interface, 
is  accessed  via  this  set  of  operations.  Interfaces  and  object  implementation  are  totally  separated.  This  allows 
having  multiple  implementations  of  an  object,  but  still  a  unique  interface. 

An  object  satisfies  an  interface  if  it  provides  its  service  through  the  operations  of  the  interface  according  to 
the  specification  of  the  operations. 

IDL  Interface 


* 


Figure  2:  Interface  vs  Implementation 

The  basic  functionality  provided  by  the  ORB  consists  of  passing  the  requests  from  clients  to  the  object 
implementations  on  which  they  are  invoked.  In  order  to  make  a  request  the  client  can  communicate  with  the 
ORB  Core  through  the  IDL  stub  or  through  the  Dynamic  Invocation  Interface  (DII).  The  stub  represents  the 
mapping  between  the  language  of  implementation  of  the  client  and  the  ORB  core.  Thus  the  client  can  be 
written  in  any  language  as  long  as  the  implementation  of  the  ORB  supports  this  mapping.  The  ORB  Core 
then  transfers  the  request  to  the  object  implementation  which  receives  the  request  as  an  up-call  through  either 
an  IDL  skeleton,  or  a  dynamic  skeleton. 

Every  object  instance  has  its  own  unique  IOR  (Interoperable  Object  Reference),  an  identifying  electronic 
token.  Clients  use  the  IOR  to  direct  their  invocations,  addressing  to  the  ORB  that  manages  the  remote  access 
to  the  objects,  the  exact  instance  they  want  to  invoke. 

When  the  ORB  examines  the  object  reference  and  discovers  that  the  target  object  is  remote,  it  routes  the 
invocation  out  over  the  network  to  the  remote  object’s  ORB  using  standards  protocols  called  GIOP  (General 
Inter-ORB  Protocol)  and  HOP  (Internet  Inter-ORB  Protocol). 

Figure  3  depicts  the  data  flow  in  CORBA 
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Figure  3:  Data  flow  in  CORBA 


As  depicted  in  Figure  3,  any  client  that  wants  to  invoke  an  operation  on  the  object  must  use  this  IDL 
interface  to  specify  the  operation  it  wants  to  perform,  and  to  marshal  (encapsulated)  the  arguments  that  it 
sends.  When  the  invocation  reaches  the  target  object,  the  same  interface  definition  is  used  to  unmarshal  the 
arguments  so  that  the  object  can  perform  the  requested  operation  with  them.  The  interface  definition  is  used 
to  marshal  the  results  for  their  trip  back  and  to  unmarshal  them  when  they  reach  their  destination. 
Correspondences  between  ISO-OSI  and  CORBA  Client-Server  levels  architectures  are  shown  in  Figure  4 


Figure  4:  Correspondences  between  ISO-OSI  layers  and  CORBA  Client-Server  levels  architectures 
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4.  DEVELOPING  AN  AIR  DEFENCE  SYSTEM  NETWORK 
WITH  APPLICATIONS  IN  CORBA 


Many  application  domains,  such  as  an  Air  Defence  System,  require  real-time  guarantees  from  the  networks, 
operating  systems,  and  middleware  components  to  achieve  their  quality  of  service  (QoS)  requirements.  In 
addition  to  providing  end-to-end  QoS  guarantees  and  interoperability  between  each  element  of  the  System, 
applications  in  these  domains  have  to  be  flexible  and  reusable.  Requirements  for  flexibility,  reusability  and 
interoperability  motivate  the  use  of  object-oriented  middleware  like  the  Common  Object  Request  Broker 
Architecture  (CORBA). 

The  core  of  CORBA  architecture  is  focused  on  the  concept  of  layered  pluggability  where  various 
components  of  the  middleware  may  be  “plugged”  (included  to)  or  unplugged  (removed  from)  on  as-needed 
basis  allowing  flexible  middleware  configuration.  End-users  call  and  receive  data  streams  (object’s 
operations  request  and  results)  from  different  sources  without  the  need  to  know  the  exact  location  of  the 
sources  or  to  have  specialized  processors  to  capture  the  multimedia  data. 

For  MEADS,  as  it  is  depicted  in  Figure  5,  in  order  to  implement  the  CORBA  architecture  in  a  distributed  and 
netted  network  the  objects  are  covered  by  the  elements  of  the  System  MEI  (Major  End  Items),  Sensors, 
Launchers  and  TOC  and  the  object’s  applications  are  represented  by  their  functionality  (“target  tracks”, 
“target  identification”,  etc.). 


BMC4I  Software  Structure  and  Embedding  of  P&F  Modules 


Application 
Domains 
(8  domains) 


Objects 
to  perform 
tasks  in  a 
components 


BMC4I  S/W 


Planning 

Fighting 

Training 

Logistics 

1 

_ 1  1  _ 

Resources 

Fire  Control 

Sensor/Lnchr 

Interfaces 

Tracker 

OSI  Application  Layer 
(layer  #7)  Objects 


Object  Oriented  S/W  structure  is  the  platform  for  P&F  integrations 


Figure  5:  BMC4I  Software  structure 
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The  configuration  network  proposed  is  an  hybrid  configuration:  each  element  is  ready  to  share  its 
applications  but  always  passing  through  the  TOC  that  represents  a  client  for  a  fire  unit,  but  could  also  be  seen 
as  a  server  in  a  Battery  or  in  a  wider  Integrated  Defence  System. 

A  client  (TOC)  can  invoke  an  operation  to  the  server  object  by  sending  it  a  Request  message.  This  type  of 
message  contains  all  the  information  that  is  required  to  make  a  remote  method  invocation.  A  server  object 
(sensors,  launchers)  responds  to  a  client’s  invocation  containing  the  response  to  the  Request.  Figure  6  shows 
the  hybrid  configuration  concept  described  above. 

Adopting  the  same  architecture  other  “objects”  may  be  in  easy  way  “plugged”  to  the  system  realizing 
successfully  the  concept  of  the  scalability,  evolvability,  and  interoperability. 


Figure  6:  Hybrid  configuration  network 


In  Corba  Architecture,  every  object  instance  has  its  own  unique  Interoperable  Object  Reference  (IOR),  well- 
identified  and  unique  electronic  token.  The  clients,  the  TOC  or  other  C2  units,  use  the  IOR  to  direct  their 
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invocations,  identifying  to  the  ORB  (Object  Request  Broker)  that  manages  the  remote  access  to  the  objects, 
the  exact  instance  they  want  to  invoke.  When  the  ORB  examines  the  object  reference  and  discovers  that  the 
target  object  is  remote,  it  routes  the  invocation  out  over  the  network  to  the  remote  object’s  ORB  using  GIOP 
and  HOP.  Figure  3  depicts  the  data  flow  in  CORBA. 

GIOP  is  a  protocol  that  defines  an  ensemble  of  messages  available  between  client  and  server  underlining  the 
communication  syntax  between  different  ORBs. 

GIOP  use  a  standard  binary  format  for  the  transmission  of  the  IDL  type  messages,  called  Common  Data 
Representation  (CDR)  that  define  the  order  and  the  alignment  of  the  Bytes  for  each  IDL  message. 

The  characteristic  of  the  CDR  coding  permit  a  good  efficiency  in  the  marshalling  technique  but  the  length  of 
the  messages  is  not  optimum. 

The  receiver  node  sees  the  messages  as  a  stream  of  not  formatted  bit. 

In  GIOP  protocols  are  defined  eight  types  of  messages  whose  only  two  are  really  important  for  the  flow  of 
the  messages  between  client  and  server: 

Request:  the  client  sends  this  kind  of  message  to  the  server  in  order  to  invoke  one  particular 
operation. 

Reply :  the  server  sends  this  kind  of  message  to  the  client  in  order  to  satisfy  the  invocation. 

The  duty  of  the  IIOP  protocol  is  to  link  GIOP  protocol  with  TCP/IP  (mapping),  defining  all  the  information 
regarding  the  address  of  the  objects. 

These  informations  are  included  in  the  IOR  of  the  object,  so  the  IIOP  has  only  to  specify  in  which  mode  the 
IOR  address  this  kind  of  information. 

Figure  7  shows  the  general  structure  of  the  CORBA  Message. 


IP  Header 

TCP  Header 

GIOP  Message  Header 

Variable-length  GIOP  Message 

19  byte 

19  byte 

12-byte 

Body 

Figure  7:  Structure  of  a  CORBA  message 


5.  SIMULATION  DATA  TOOL 


The  data  load  budget  of  the  netted  and  distributed  Air  Defence  System  architecture  under  study,  has  been 
analysed  using  a  NAMEADSMA  customized  simulation  Tool,  characterized  in  input  by  the  Action  History 
output  file  of  EADSIM  (Extended  Air  Defence  SIMulation)  that  runs  on  a  predefined  and  user-selectable 
scenario  and  the  set  of  CORBA  Messages.  The  type  of  scenarios  used  vary  from  Mass  Attack  (Many-on- 
Many)  to  a  One-on-One  configuration. 

The  Tool  implements  a  mapping  between  EADSIM  messages  taken  from  the  EADSIM  output  Action 
History  file  and  the  CORBA  messages,  taken  into  account  the  estimated  timeline  of  the  System. 

Figure  8  shows  the  Network  data  load  Simulation  tool  functionalities  and  how  the  various  entities  involved 
are  interfaced  each  other. 
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Figure  8:  Network  Data  load  Simulation  tool 


This  simulation  tool  allows  the  operator  to  select,  through  a  user-friendly  interface,  the  data  bit-rate,  the 
Sensor  tracking  frequency  and  in  a  future  version  it  will  also  incorporate  the  possibility  to  compare  directly  a 
TDMA  implementation  with  the  features  of  a  CDMA  one. 

Figure  9  and  10  show  the  result  of  the  simulation  data  tool:  as  a  result  of  running  the  simulation  tool  the 
network  data  load  of  the  system  under  analysis  is  shown  in  figure  9  detailing  the  load  of  the  single  ME1 
while  chart  in  figure  1 0  details  the  load  of  the  whole  system  in  percentage  as  a  function  of  time. 


Figure  9:  Network  Data  load 


Figure  10:  %  Time  load  as  a  function  of  time  (sec) 


One  of  the  possible  applications  of  this  Simulation  tool  is  to  analyse  and  establish  the  interoperability  degree 
between  two  different  Air  Defence  systems,  between  single  components  (ME1)  of  different  Weapons 
Systems  characterizing  them  as  distributed  application  shared  on  the  same  CORBA  network. 
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ABSTRACT 

To  be  able  to  model  systems  for  C2  we  have  to  evaluate  and  find  appropriate  methodology’  for  modelling 
and  representation  of  our  knowledge  about  military >  organisations  and  military  behaviour.  Militaiy 
organisation  and  military’  behaviour  are  important  parts  of  C2. 

In  this  paper  we  present  a  study  of  modelling  militaiy  organisation  and  military  behaviour  in  a  generic 
manner,  using  two  different  knowledge  representation  techniques:  the  Unified  Modeling  Language 
(UML)  and  Bayesian  Networks.  The  class  diagram  that  is  provided  by  UML  is  well  suited  for 
representing  militaiy  organisations  whose  structure  is  well-known,  since  military >  units  and  their 
interrelations  can  be  represented  as  classes  and  interrelations  between  the  classes.  On  the  other  hand,  it 
is  a  much  harder  task  to  represent  militaiy  organisations  that  are  not  well-known  or  militaiy  behaviour 
because  of  the  uncertainty >  associated  with  them.  Different  behaviours  are  triggered  in  different 
environments  using  different  doctrines,  and  the  outcomes  of  the  behaviours  are  uncertain.  Due  to 
complexity >,  time  constraints  and  war  friction,  causal  relations  between  different  factors,  which  play  an 
important  role  in  warfare,  may  be  uncertain. 

Bayesian  Networks  seems  to  be  a  reasonable  choice  for  representing  uncertain  military  behaviour  as 
well  as  uncertain  military’  organizations,  since  this  method  combines  uncertainty  and  a  priori  knowledge 
in  a  homogeneous  way.  We  can  compare  those  models  and  facilitate  the  verifying  process.  As  result  we 
get  a  more  reliable  BN  and  the  modelling  time  decreases. 


1.0  INTRODUCTION 

Our  intention  with  this  paper  is  to  highlight  the  need  of  interaction  between  two  different  modelling 
techniques,  Unified  Modelling  Language  (UML)  and  Bayesian  Networks  (BN).  Despite  the  fact  that 
these  techniques  are  very  different  and  are  used  for  different  purposes,  we  propose  an  approach  generic 
UML  modelling  of  military  organisation  and  military  behaviour  as  a  first  step  towards  modelling  with 
BN.  Modelling  with  BN  involves  nets  with  high  complexity  and  a  structured  overview  is  required.  UML 
class  diagrams  enable  a  good  visual  overview  of  class  structure  and  relations  between  different  classes. 
Having  a  UML  structure  in  the  “background”  makes  it  easier  for  us  to  implement  large  BN  networks. 
Finally  we  can  compare  those  models  and  facilitate  the  verification  process.  As  result  we  get  more 
reliable  BN  models  and  modelling  time  decreases. 

Military  organisation  and  behaviour  are  described  in  military  doctrines.  The  first  issue  is  how  to  model 
doctrines  on  a  conceptual  level  and  the  second  issue  is  how  to  implement  these  concepts  in  a  concrete 
model.  The  connection  between  the  conceptual  level  and  a  concrete  model  is  also  discussed  in  this  paper. 
Modelling  on  the  conceptual  level  has  been  performed  by  using  textual  and  graphical  documentation 
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techniques  associated  with  the  Unified  Modelling  Language  (UML)  and  Bayesian  Networks  (BN), 
respectively.  Implementation  of  the  model  was  performed  in  MATLAB.  The  implementation  is  a  BN 
model  which  uses  some  of  the  classes  and  variables  represented  by  a  UML  model. 

In  this  paper  we  will  represent  a  doctrine  class  diagram  in  UML  with  focus  on  ground  forces,  as  well  in  a 
BN  model,  and  finally  discuss  UML  and  BN  as  modelling  techniques.  The  BN  model  that  we  have 
implemented  represents  a  relatively  small  part  of  the  UML  doctrine  model.  The  UML  model  can  be  used 
for  more  general  purposes  while  the  BN  model  is  used  to  model  the  behaviour  of  a  relatively  small 
hostile  force  unit  that  acts  in  a  certain  environment. 

The  importance  of  developing  generic  models  in  command  and  control  (C2)  is  increasing  due  to  issues  of 
co-ordination,  co-operation,  training,  decision  support  etc.  When  modelling  warfare  a  plethora  of  factors 
has  to  be  considered.  In  such  complex  problems  the  increasing  need  for  classification  of  knowledge 
arises.  We  found  it  important  to  perform  such  a  classification  in  a  generic  manner.  The  class  models 
could  then  be  reused  with  some  modification  and  should  be  easy  to  update.  Consequently,  the  modeling 
expert  can  concentrate  on  one  part  of  the  model  at  time.  E.  g.,  one  generic  model  of  a  military 
organisation  and  military  behaviour  can  be  reused  for  modelling  different  doctrines  and  for  different 
purposes  by  using  a  well-known  modelling  technique.  Consequently,  we  have  performed  a  UML 
classification  of  doctrines  in  a  generic  manner.  BN  are  able  to  represent  uncertainty  that  arises  when 
modelling  doctrines,  e.  g.  fog  of  war,  especially  when  modelling  enemy  organisation  and  military 
behaviour. 

2.0  MODELLING  TECHNIQUES 
2.1  Unified  Modelling  Language 

In  this  work,  we  use  two  different  modelling  techniques.  The  first  one  is  the  Unified  Modelling 
Language  (UML,  see  [1]).  UML  is  a  set  of  graphical  description  techniques  for  specifying,  visualising, 
implementing  and  documenting  object-oriented  systems  [2],  The  aspect  of  the  Unified  Modelling 
Language  (UML)  that  has  been  used  in  this  paper  is  the  class  diagram.  We  have  not  performed  sequence 
diagram  representation  in  UML  because  of  the  tremendous  complexity  of  the  military  operations 
considered  here. 

The  class  diagram  in  UML  provides  graphical  representation  of  object  types,  also  called  classes.  The 
model  describes  relations  between  classes  in  a  uniform  way  by  using  a  standardised  representation.  A 
class  is  a  template  containing  mutual  properties  of  a  group  of  objects.  Types  of  the  objects,  classes,  may 
be  everything  from  physical  objects,  e.g.  tank,  to  abstract  objects  such  as  plan  and  task.  A  more  general 
definition  of  the  class  concept  is  that  the  class  is  a  set  of  objects  with  the  same  behaviour  which  are  of  the 
same  type.  “ Object-oriented  methods  also  provide  means  to  increase  reuse  of  design  efforts,  including 
the  concepts  of  patterns  and  the  generalization/inheritance  relation.  These  means  offer  the  possibility  to 
describe  problems  and  to  model  properties  of  objects  in  a  generic  fashion,  considering  only  common 
features  before  instantiation  for  the  specific  case”  [3]. 

When  we  want  to  describe  a  class  model  in  UML  we  first  identify  interesting  classes  and  after 
performing  that  step  we  describe  relations  between  them.  Consequently,  we  make  a  generic  structure  that 
can  be  used  for  implementation  for  different  purposes. 

The  first  step  towards  a  UML  modeling  was  to  collect  knowledge  about  military  organisation  and 
military  behaviour.  Most  of  this  knowledge  has  been  collected  from  doctrine  manuals.  In  our  model  we 
use  a  representation  of  Swedish  doctrines,  although  in  generic  manner.  By  using  this  kind  of  modelling 
approach,  the  UML  structure  can  be  reused/generalised  to  model  other  regular  military  organisations 
with  some  modifications. 
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Doctrines  provide  hints  about  how  military  tasks  should  be  carried  out.  This  means  that  some  of  the 
military  behaviours  can  be  classified.  Given  information  about  environment,  force  balance,  opponent’s 
position  and  other  rules  that  have  influence  on  military  behaviour  we  can  say  that  some  behaviours  are 
more  probable  to  occur  in  some  situations.  UML  has  a  very  good  expressive  power  for  classification. 
Class  diagrams  in  UML  give  very  good  overview  but  we  cannot  say  anything  about  the  probability  that  a 
given  class,  in  this  case  a  class  describing  a  particular  behaviour,  will  occur.  E.  g.  we  found  it  difficult  to 
express  how  using  UML  a  class  representing  frontal  attack  behaviour  of  some  hostile  military  unit  is 
likely  to  occur  given  the  information  that  we  are  close  to  the  enemy  and  the  fact  that  visibility  is  good.  In 
some  cases  certain  classes  are  irrelevant  and  in  other  cases  they  are  important. 

Relations  between  attributes  of  different  classes  cannot  be  represented  in  UML  class  diagrams.  Instead, 
in  a  UML  class  diagram  we  specify  relations  between  different  classes. 

On  the  other  hand,  the  advantage  is  that  the  principle  of  encapsulation  makes  it  possible  to  build 
implementations  that  have  parts  which  are  more  autonomous,  objects  in  UML. 

In  BN  instead  of  attributes  we  have  variables.  We  see  the  attribute  as  a  generalisation  class  of  class 
variable  in  UML. 


Figure  1:  UML  model  of  a  platoon 


The  model  in  Figure  1  is  developed  and  improved  from  an  even  more  generic  model  of  C2,  see  [3].  The 
interpretation  of  the  figure  above  is  that  one  Platoon  consists  of  three  or  four  Groups,  one  Platoon 
Commander  and  one  Deputy  Commander.  The  Platoon  has  an  attribute  Formation  with  four  possible 
values:  Lead,  Battle  Line,  Stepped  Formation  and  Battle  Triangle.  This  variable,  attribute  in  UML, 
will  be  represented  in  BN  with  these  values.  Platoon  is  an  Organisation .  The  subset  of  Physical 
Resource  class  is  a  class  of  Technical  Artefact  which  contains  attributes  that  correspond  to  the  technical 
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equipment  of  the  platoon  in  this  case.  As  we  see  in  this  class  diagram  we  do  not  have  any  description  of 
relations  between  attributes. 

When  modelling  a  hostile  military  organisation  we  do  not  always  have  complete  information  about  it.  E. 
g.  we  may  not  know  how  many  tanks  an  enemy  tank  platoon  consists  of.  Let  us  say  that  in  other  cases 
hostile  platoon  consists  of  three  or  four  tanks,  in  some  cases  there  are  also  some  other  vehicles  in  a 
platoon.  In  UML  we  can  express  this  relation  as  “the  platoon  consists  of  three  to  four  groups”.  A 
statistical  interpretation  of  that  statement  may  be  the  uniform  distribution  over  the  number  of  groups. 

That  implies  that  the  hypotheses  three  and  four  groups  are  equally  probable.  There  is  no  convenient  way 
in  UML  to  express  for  example  our  knowledge  that  four  groups  is  more  frequent  than  three  groups.  A 
deficiency  of  the  UML  is  its  inability  to  represent  uncertainty  in  a  comprehensive  way. 

2.2  UML  doctrine  model 

In  Figure  1  we  showed  the  model  of  a  platoon.  In  the  same  manner  Figure  2  shows  a  company  model. 
This  model  also  represents  the  relation  between  company  class  and  platoon  class  hence  obtaining  a 
hierarchical  representation. 


Figure  2:  Company  description  with  UML 

It  is  not  enough  when  modelling  military  doctrines  to  describe  relations  between  different  units,  their 
roles,  which  resources  are  they  part  of,  and  which  resources  are  put  to  their  disposal.  Military  behaviour 
is  however  an  important  part  of  doctrines  that  is  not  part  of  the  model.  In  concrete  situations  there  is  a  list 
of  the  military  behaviours/actions  to  be  executed.  In  Figure  3  we  show  a  model  in  which  relations 
between  military  behaviour  as  a  part  of  planning,  military  organisation  and  environment  are  represented. 
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Figure  3:  Planning,  doctrine  and  environment 

We  recognise  this  kind  of  problem  in  AI  as  the  agent  planning  problem  under  uncertainty;  see  [4],  As  we 
see  in  Figure  3,  environment  rules  and  doctrine  rules  are  subsets  of  more  general  rules  in  an  agent 
planning  problem.  Utility-based  rules  represent  all  rules  that  are  not  described  in  manuals  but  are 
frequently  used.  Some  military  or  paramilitary  organisations,  for  instance,  lack  doctrine  rules.  Plan  and 
task  are  assigned  to  the  role  which  can  be  for  example  a  commander  of  a  military  unit  or  tank  driver.  In 
order  to  solve  the  task  and  execute  the  plan  a  role  has  to  use  resources.  The  role  can  be  part  of  a  larger 
plan  and  be  subordinated  to  a  resource,  e.g.  platoon  member  is  subordinate  to  platoon. 

Part  of  the  model  is  also  the  environment,  which  plays  an  important  role  when  making  plans.  It  is 
regarded  by  military  commanders  both  as  opportunity  and  as  restriction  to  execution  of  their  plans. 
Infonnation  about  the  opponent  is  also  important  when  making  own  plans.  However  representation  of 
some  “generic”  opponent  is  not  performed  in  our  UML  diagrams,  although  it  was  modelled  with  our  BN 
model  of  a  particular  hostile  tank  company. 

2.3  Bayesian  Networks 

In  general  when  modelling  warfare  we  have  to  deal  with  uncertainties.  Prediction,  fusion  of  the  uncertain 
information,  war  friction,  enemy  courses  of  action  etc.,  are  examples  of  where  a  high  degree  of 
uncertainty  is  involved. 

Bayesian  Networks  is  a  statistical  modelling  method  used  to  represent  uncertain  causal  relations  between 
different  statistical  variables. 
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The  graphical  representation  of  BN,  is  different  from  that  of  UML  and  uses  nodes  and  arcs 
representation.  Only  one  kind  of  relation  between  variables  is  described.  This  kind  of  relation  is  also 
called  “influence  relation”  hence  BN  is  also  subset  of  influence  diagrams. 

Each  node  represents  a  variable  that  can  be  either  discrete  or  continuous.  Variables  and  its  states  are 
represented  by  conditional  probability  distributions  also  called  subjective  probabilities.  BN  is  also 
denoted  belief  network  since  they  describe  our  belief  about  the  state  of  the  variables. 

When  new  evidence  arrives,  the  probability  density  function  over  each  variable’s  states  change  and  new 
belief  propagates  through  the  network  weighted  by  our  subjective  probabilities.  An  advantage  of  the  BN 
is  that  our  knowledge  is  implemented  in  a  fragmented  manner.  We  only  have  to  “explain”  how  a 
particular  node  depends  on  its  parents.  E.  g.  in  Figure  4  we  define  the  probability  density  function  of  the 
variable  WetGrass.  The  variables  that  make  direct  influence  on  the  variable  are  called  parents.  WetGrass 
in  this  example  has  parents  Sprinkler  and  Rain.  The  a  priori  probability  density  function  of  variable 
WetGrass  does  not  model  influence  of  the  variable  Cloudy.  Elowever,  let  us  say  that  new  evidence 
arrives.  The  statement  of  the  new  evidence  is  that  we  know  that  the  weather  is  cloudy,  Cloudy  =  True, 
this  evidence  will  propagate  through  the  network  and  make  influence  on  our  belief  about  if  grass  is  wet 
or  not.  The  process  where  weighing  the  new  evidence  with  our  subjective,  a  priori,  knowledge  is 
performed  is  denoted  statistical  inference. 
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Figure  4:  An  Example  BN  [5] 

When  using  BN  we  can  infer  evidence  in  all  directions  by  using  the  Bayes  rule.  E.  g.  we  can  answer  the 
question  what  is  the  probability  that  the  sprinkler  was  on  if  we  perceive  that  the  grass  is  wet.  The  causal 
relations  give  only  a  description  of  the  model. 
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According  to  [6]  the  formal  definition  of  BN  is: 

•  A  set  of  variables  and  set  of  directed  edges 

•  Each  variable  has  a  finite  set  of  mutually  exclusive  states 

•  The  variables  together  with  the  directed  edges  form  directed  acyclic  graph  (DAG) 

•  To  each  variable  A  with  parents  B1  ..Bn  there  is  attached  conditional  probability  table  P(A|  B1  .. 
Bn) 

Mathematically  expressed: 

n 

P(X\..Xn)  =  Y[P(Xi  |  par(Xij) 

1=1 

Where  n  is  the  number  of  the  nodes  in  the  network  and  A)  represents  a  stochastic  variable  no.  i  of  the  BN. 

When  we  describe  a  time-dependent  BN  we  speak  about  Dynamic  Bayesian  Networks  (DBN).  It  consists 
of  several  layers  of  BN  with  the  same  structure.  The  additional  influences  in  DBN  are  the  variables  of  the 
previous  step(s)  that  make  influence  in  variables  for  future  step(s).  Note  that  the  term  “dynamic”  means 
that  we  are  modelling  a  dynamic  system,  not  that  the  network  changes  over  time  [7].  The  variable  values 
changes  over  time  but  the  network  topology  remains  same. 

The  problem  of  how  to  handle  complexity  arises  when  we  want  to  describe  behaviour  of  many  military 
units  instead  of  one  military  unit.  The  BN  becomes  very  large  with  many  state  variables.  When  we  model 
a  clear  conception  of  how  the  system  works  is  required.  As  the  number  of  variables  grows,  the  difficulty 
of  envisioning  such  a  model  increases  enormously  [8].  Therefore  the  process  of  classification  and 
describing  relations  between  classes  is  required. 

The  important  issue  is  how  to  build  a  BN  from  the  UML  class  diagram.  As  a  first  step  we  create  a  BN 
representing  a  military  unit,  a  platoon  in  this  case.  The  hostile  platoon’s  behaviour  depends  on  factors 
like  environment,  platoon  doctrines  and  superior  unit  behaviour,  a  hostile  company  in  this  case.  When 
we  implement  the  BN  we  realised  that  we  cannot  use  the  principle  of  reuse/generalisation  more  than 
copy  and  paste  of  the  BN  fragments.  In  this  particular  example  we  realised  that  we  had  to  copy  the  BN 
representing  platoon  three  times.  The  drawback  of  this  BN  is,  beside  the  fact  that  we  had  to  manually 
rename  variables  for  platoon  two  and  three,  that  when  we  wanted  to  change  a  structure  of  the  platoon 
representation  we  had  to  change  each  platoon  fragment.  The  structure  of  the  UML  military  unit  and 
planning  model  facilitated  the  work  of  modelling  (D)BN  representing  a  hostile  company  but  no 
formalism  has  yet  been  applied. 

2.4  A  Hostile  Company  Bayesian  Network  Model  Example 

In  this  section  we  describe  a  particular  BN  model  that  is  used  for  recognition  of  enemy  plans. 
On-line  multi-agent  stochastic  policy  recognition  aims  to  detect  which  policies  an  agent  or  group  of 
agents  are  executing  by  observing  the  agents'  actions  and  by  using  a  priori  knowledge  about  the  agents  in 
a  noisy  environment.  The  method  chosen  for  the  representation  of  this  task  is  Bayesian  inference  using 
dynamic  Bayesian  nets.  The  inference  is  intended  to  derive  belief  measures  for  enemy  plans. 

In  military  applications  the  issue  is  how  to  recognise  certain  military  behaviours  of  the  enemy.  Using  the 
movement  pattern,  speed,  distance,  visibility,  maneuverability  distance  to  presumptive  target  etc.,  it 
might  be  possible  to  fuse  the  acquired  knowledge  about  the  enemy  and  use  it  in  policy  recognition.  The 
advantage  would  be  that  military  commanders,  having  better  knowledge  about  the  enemy’s  intentions, 
will  be  able  to  act  earlier.  The  ability  to  act  preventively  increases  as  well. 

The  purpose  of  the  network  is  to  make  qualified  estimation  of  the  opponent’s  behaviour  based  on 
observations,  knowledge  about  opponent’s  doctrines  as  well  as  data  from  the  terrain. 
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As  the  first  step  in  making  a  company  BN,  we  make  a  BN  of  a  single  hostile  platoon.  We  specify 
variables  in  the  graphical  diagram.  After  that,  the  causal  relationships  between  variables  are  specified. 
Finally,  we  define  conditional  probabilities  to  “explain”  how  a  certain  variable’s  values  depends  on  its 
parents  values.  E.  g.  we  previously  mentioned  variable  Formation,  see  section  2.  1,  that  may  have 
following  values:  Lead,  Battle  line,  Stepped  Formation  and  Battle  Triangle.  We  define  a  conditional 
probability  distribution  over  all  possible  combinations  of  values.  In  Figure  5  we  see  the  node 
representing  the  variable  formation. 


Figure  5:  Planning,  doctrine  and  environment 
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Formation  has  following  parents:  platoon  manoeuvrability,  platoon  policy  and  cover.  By  defining  our 
probability  distributions  we  model  our  a  priori  knowledge.  E.  g.  the  formation  battle  line  is  less  probable 
to  be  used  by  the  hostile  formation  when  the  manoeuvrability  is  bad.  The  formation  battle  triangle  is 
more  probable  to  occur  in  this  case  if  the  variable  of  platoon  policy  is  attack.  The  variables  formation, 
distance  to  presumptive  target,  and  direction  of  guns  are  used  to  connect  observations  to  different 
policies.  We  denote  these  nodes  doctrinal  nodes. 

After  building  a  platoon  model  we  define  a  company  model  that  consists  of  three  platoons.  In  this  case 
we  intended  to  define  a  platoon  class  with  three  instances.  But  modelling  with  classical  BN  does  not 
support  this  kind  of  approach.  Instead  we  had  to  perform  a  cut  and  paste  process  and  when  we  wanted  to 
change  the  model  of  a  platoon  we  had  to  change  it  in  all  the  three  instances. 

The  second  drawback  of  the  BN  was  that  connection  between  platoon  and  company  model  is  only  via 
variables.  The  principle  of  encapsulation  does  not  exist  in  classical  BN.  One  of  the  problems  is  that 
fragmentation  of  the  BN  could  violate  laws  of  the  statistical  inference. 

The  hostile  company  BN  model  was  implemented  in  MATLAB.  It  takes  environment,  doctrines  and  new 
information  about  enemy  forces  movement  into  account.  We  are  able  by  using  this  model  to  observe  the 
most  probable  policies  that  the  enemy  is  executing  on  different  abstraction  levels. 


3.0  DISCUSSION  AND  CONCLUSIONS 


The  UML  and  BN  are  two  different  modelling  methods  for  different  purposes  and  for  different  modelling 
approaches.  Nevertheless  we  propose  a  modelling  approach  that  combines  knowledge  incorporated  in 
UML-class  diagrams  when  modelling  BN.  The  reason  is  that  when  using  a  generic  well  defined  structure 
the  process  of  modelling  large  and  complex  BN  is  facilitated. 

In  order  to  facilitate  future  modelling  process,  the  concept  of  Object-Oriented  Bayesian  Networks 
(OOBN)  should  be  studied.  Especially  this  concept  could  be  useful  when  modelling  large  military 
formations  with  (OO)BN.  This  principle  of  modular  and  reusable  representation  of  a  BN,  OOBN,  has 
been  applied  in  a  probabilistic  representation  language  (SPOOK);  see  [8]. 

Some  parts  of  programming  code  of  OO-languages  as  Java  and  C++  can  be  generated  directly  from 
UML.  Is  it  possible  to  develop  a  formalism  that  generates  at  least  some  parts  of  a  BN  from  UML  in 
similar  manner?  There  are  many  obstacles  to  achieve  that.  One  of  them  is  the  difficulty  of  UML  to 
handle  uncertainty  in  a  uniform  way.  A  uniform  notation  to  express  uncertainty  in  an  easy  and 
comprehensive  manner  should  be  developed  for  UML. 

Also  the  inconsequent  fragmentation  of  BN  in  classes  could  violate  rules  of  statistical  inference. 
However,  we  are  convinced  that  a  new  kind  of  approach  of  designing  BN  is  required  to  achieve  better 
compatibility  with  OO-methods. 
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ABSTRACT 

The  need  of  information  on  tactical  battlefield  will  increase  in  future  battles.  Not  only  to  gain  information 
on  battlefield,  but  also  to  convey  it  where  it  is  needed  on  time,  will  be  very  important.  The  next  generation 
mobile  tactical  communications  systems  will  provide  a  robust,  reliable,  secure  and  flexible  network  to  the 
mobile  users  of  tactical  battlefield.  However,  it  is  a  question  under  interest  to  predict  the  impacts  of 
different  battle  conditions  on  their  performance.  We  conducted  a  simulation  study  of  a  messaging  system 
of  a  model  brigade  which  mobile  users  use  TDMA  (Time  Division  Multiple  Access)  radios  and  TDMA 
technique  for  channel  access.  We  identify  a  set  of  components,  which  are  called  Mobile  Subscriber 
Terminals,  Personal  Subscriber  Terminals  and  Radio  Access  Points  that  make  up  mobile  wireless 
network.  The  mobile  wireless  network  can  provide  networking  facilities  and  many  simultaneous  voice  and 
data  connections  to  the  mobile  users.  The  focus  of  this  study  is  to  construct  a  simulation  model  of  a 
messaging  system  of  a  model  brigade  on  tactical  battlefield  and  to  determine  if  the  system  is  capable  of 
supporting  the  data  exchange  in  performance  criteria  under  different  conditions.  The  simulation  is 
performed  by  using  Arena  7.0  simulation  program  and  results  are  analysed  by  using  SPSS  statistical 
package  program. 

Keywords:  Simulation,  messaging  system,  mobile  wireless  network 


1.  INTRODUCTION 

The  success  of  military  operations  on  today’s  tactical  battlefield  is  closely  related  to  the  C4I  (Command, 
Control,  Communications,  Computer  and  Intelligence)  concept.  Gathering,  exploiting,  and  protecting 
information  is  critical  from  the  view  of  C4I  concept.  To  achieve  the  C4I  functions  the  existence  of  a 
secure,  robust,  reliable  and  mobile  communications  infrastructure  is  very  important.  This  infrastructure 
should  be  capable  of  conveying  messages,  data,  imagery,  and  video  files  as  well  as  voice  communications 
among  the  fixed  and  mobile  components  of  the  battle  forces  in  a  secure,  and  timely  manner. 

Advances  in  technology  affect  the  way  that  the  warfare  is  conducted.  Recent  improvements  in 
information,  computers  and  communications  technology  such  as  broadband  networks,  digital  cellular 
systems,  wireless  computer  networks,  evolving  computer  systems,  global  positioning  and  other 
technologies  opened  new  horizons  in  the  communications  systems.  Electronic  mail,  cellular  telephone  for 
voice  and  data,  vehicle  position  reporting/tracking  systems,  and  many  other  products  have  appeared.  With 
these  evolving  technologies,  today,  the  efforts  to  reach  the  goal  of  “digitizing  the  battlefield”  increased. 
The  intelligence  about  the  battlefield  such  as  the  strength  and  placement  of  the  enemy,  the  geographical 
positions  of  friendly  troops  are  tracked  and  analyzed  with  computers  and,  again  these  computers  can  be 
used  to  pass  the  information  between  components  of  the  battlefield.  These  improvements  provide  future 
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war  fighters  and  decision  makers  with  accurate  information  in  a  timely  manner. 

In  our  study,  we  develop  a  simulation  model  of  the  messaging  system  of  a  model  brigade  on  the 
battlefield.  In  the  messaging  system,  information  in  forms  of  messages,  reports  and  plans  are 
accomplished  with  personal  computers.  GPS  information  is  automatically  updated,  giving  subordinate 
units  complete  knowledge  of  the  friendly  situation;  thus  a  common  view  of  the  battlefield.  The  multimedia 
(video,  imagery)  is  one  of  the  most  important  parts  of  this  information.  The  users  of  the  system  are  mobile 
and  use  Time  Division  Multiple  Access  (TDMA)  radios  to  send  this  data.  We  examine  the  behavior  of  the 
messaging  system  to  determine  if  it  is  capable  of  supporting  the  needs  of  the  users  in  the  battlefield.  We 
also  investigate  the  significant  factors  that  affect  the  system  performance  and  their  relationships.  Finally, 
we  evaluate  the  system  under  different  types  of  operations.  The  objectives  of  this  study  are  to; 

•  develop  a  simulation  model  of  a  brigade  messaging  system, 

•  examine  the  behavior  of  the  communication  system  to  determine  if  it  is  capable  of  supporting  the 
messaging  needs  under  different  conditions  for  various  performance  measures, 

•  analyze  the  effects  of  the  model  parameters  on  the  performance, 

•  establish  the  nature  of  the  relationships  among  input  factors  and  system  responses, 

•  compare  system  responses  under  different  circumstances. 

The  outline  of  the  paper  is  as  follows:  In  Section  2,  the  system  is  briefly  described.  In  Section  3,  the 
simulation  model  is  explained  in  details  and  validation  and  verification  of  the  model  is  discussed.  The 
results  of  the  output  analysis  and  experimental  design  are  presented  in  Section  4.  Finally  concluding 
remarks  are  given  in  Section  5. 


2.  THE  SYSTEM  DESCRIPTION 

In  the  brigade  structure  that  we  model,  there  are  a  Brigade  Headquarters,  a  Communications  Company,  an 
Antitank  Company,  an  Engineer  Company,  an  Air  Defense  Battery,  an  Artillery  Battalion,  two 
Mechanized  Infantry  Battalions,  and  two  Armor  Battalions.  All  units  in  the  brigade  messaging  system  use 
mobile  subscriber  terminals  (MST)  or  personal  subscriber  terminal  (PST).  A  MST  is  a  terminal,  which  is 
used  for  both  voice  and  data  communications.  It  is  generally  mounted  on  a  vehicle.  Also,  it  may  be 
connected  to  a  computer  to  send  data,  multimedia  or  imagery.  MSTs  transmission  range  is  maximum  10 
km  in  the  line  of  sight  (LOS).  A  PST  is  a  terminal,  which  has  the  same  features  with  MST  except  output 
power,  transmission  range  and  dimensions.  Its  transmission  range  is  maximum  2  km  in  the  line  of  sight.  A 
Radio  Access  Point  (RAP)  is  the  gateway  from  LAS  network  to  the  WAS  backbone.  Units  reach  the 
subscribers  of  other  networks  via  RAP.  Units  use  TDMA  scheme  to  access  the  channel.  Units  using  the 
same  frequency  band  can  communicate  with  units  that  are  in  theirs  transmission  ranges  and  can  form  a 
radio  network  automatically  in  the  tactical  field.  Also,  units  can  act  as  a  relay  to  the  voice  or  data 
connections  of  other  units  without  interrupting  communication  services  to  its  own  user.  For  voice  calls  and 
data  connections,  a  maximum  of  3  and  5  hops  are  available  respectively,  while  real-time  video 
transmission  is  only  available  for  the  destinations  in  the  transmission  range.  Units  contain  internal  GPS 
receivers  and  obtain  position  location  information  from  the  GPS  system.  The  GPS  information  is 
automatically  distributed  in  the  network. 

There  are  many  types  of  data  including  voice  over  radio,  orders,  operations  plans,  reports,  maps,  real-time 
video  files,  etc.  that  the  users  will  exchange  in  the  system.  However,  we  classify  these  data  into  four 
groups  as  voice  calls,  messages,  real-time  video,  and  other  data  files.  The  transmission  speeds  to  send 
these  data  are  4.8  Kbps,  9.6  Kbps,  64  Kbps,  and  9.6  Kbps  and  the  needed  number  of  channels  to  realize 
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the  transmission  are  2,  4,  24,  and  4  respectively. 

We  use  a  distributed  asynchronous  version  of  Bellman-Ford  algorithm,  which  is  in  the  class  of  table- 
driven  routing  protocols  in  our  study.  In  this  protocol,  each  user  holds  a  routing  table  containing  the  length 
of  the  shortest  path  to  the  every  destination  in  the  network.  An  update  packet  is  broadcasted  by  a  node 
when  a  topological  change  is  detected.  This  packet  consists  of  only  changing  nodes.  Every  node  updates 
its  routing  table  according  to  this  information.  When  an  update  packet  is  received  from  a  neighbor  node, 
an  acknowledgement  of  the  update  packet  is  sent  to  the  neighbor  node.  This  process  will  be  repeated  until 
all  the  nodes  have  updated  their  routing  tables.  Also,  each  node  broadcasts  its  routing  table  periodically. 
The  update  data  is  kept  for  a  while  to  wait  for  the  arrival  of  the  best  route. 

We  use  distributed  time  slot  assignment  protocol  (DTSAP)  [1,2]  for  channel  access.  DTSAP  is  in  the  class 
of  conflict-free,  dynamic  allocation,  reservation  based,  multiple  access  protocols.  In  this  protocol,  every 
unit  has  its  own  control  channel,  which  is  designated  by  RAP.  In  control  channel  the  unit  broadcasts  its 
position  information  and  call  related  information  to  the  network.  A  frame  consists  of  28  data  channels. 
Using  DTSAP,  transmission  of  data  or  making  a  voice  call  occurs  in  a  two-stage  procedure.  In  the  first 
stage,  a  connection  between  source  and  destination  node  is  established  and  in  the  second  stage  data  is 
transmitted  through  the  route  or  voice  call  is  made.  When  a  node  wants  to  make  a  connection  with 
destination  node,  it  first  sends  a  connection  request  packet  to  the  destination  node  if  it  is  in  transmission 
range,  or  to  the  next  hop  in  the  route  to  the  destination  if  it  can  be  reachable  in  allowed  number  of  hops. 
This  call  request  packet  involves  the  address  of  the  destination  node,  number  of  the  channel  needed  and 
the  data  channels  that  the  node  cannot  broadcast  and  receive.  Upon  receipt  of  connection  request  packet, 
the  relay  unit  selects  the  channels  for  transmission  under  following  constraints: 

•  The  source  node  and  relay  unit  cannot  broadcast  or  receive  from  the  data  channels  dedicated  for 
other  transmissions. 

•  The  source  node  cannot  broadcast  from  the  data  channels  that  its  neighbors  receive  and  the 
neighbors  of  relay  unit  broadcast. 

•  The  source  node  cannot  receive  from  the  data  channels  that  its  neighbors  broadcast. 

•  The  relay  unit  cannot  broadcast  from  the  data  channels  that  its  neighbors  receive  and  the 
neighbors  of  the  source  node  broadcast. 

•  The  relay  unit  cannot  receive  from  the  data  channels  that  its  neighbors  broadcast. 

If  the  channels  are  available,  it  sends  a  connection  confirmation  packet  that  includes  the  selected  data 
channels.  Otherwise,  the  connection  request  is  rejected.  If  the  relay  unit  is  not  the  destination,  it  starts  the 
next  leg  of  the  connection  towards  the  destination  node.  After  a  connection  is  established,  the  destination 
node  sends  a  call-accepted  packet  back  to  the  source  using  data  channels.  After  the  call  accepted  packet  is 
received,  the  source  node  starts  transmission  of  data.  The  communications  between  source  and  destination 
node  is  full  duplex  which  means  the  source  and  destination  node  can  send  data  to  each  other 
simultaneously.  At  the  end  of  every  packet  the  destination  node,  if  it  has  successfully  received  the  packet, 
will  return  an  ACK  (acknowledgement)  packet  to  the  source  node.  The  source  node  will  retransmit  the 
packet  if  it  had  not  received  an  ACK  packet  after  a  defined  period.  When  a  node  detects  a  new  neighbor 
during  transmission,  it  sends  a  resolve  conflict  packet,  its  time  slot  assigmnent  table  and  its  routing  table 
to  the  new  neighbor.  The  neighbor  terminates  all  connections  that  have  a  conflict  and  it  broadcasts  its 
revised  routing  and  time  slot  assignment  tables  in  its  control  channel.  All  nodes  update  their  routing  tables 
according  to  new  topology.  After  all  data  transmitted  or  if  a  node  determines  that  it  has  no  longer 
connected  to  a  node  in  the  route,  to  terminate  the  connection,  source  node  sends  a  clear  request  packet  in 
the  data  channel.  Upon  receipt  of  clear  request,  the  destination  node  and  the  nodes  on  the  route  sends  a 
clear  confirmation  packet  from  their  control  channels  consecutively,  and  the  neighbors  update  their  tables. 
This  completes  the  data  transmission. 
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3.  SIMULATION  MODEL 

It  is  always  desirable  to  obtain  answers  to  the  questions  by  analytical  solutions.  But,  because  of  the 
complex  nature  of  the  system  and  dynamic/stochastic  elements,  simulation  model  is  used  to  model  and 
analyze  the  system.  First  of  all,  the  tactical  communication  system  under  consideration  has  many 
stochastic  elements  such  as,  the  call  arrival  rates  varies  for  each  user,  the  destruction  of  users  may  occur  at 
an  unknown  time,  the  available  channel  capacities  differs  according  to  the  geographical  position  of  users. 
There  are  many  analytical  studies  for  queuing  systems  of  communication  networks.  But  the  systems  are 
mostly  continuous  and  the  state  variables  change  continuously  over  time.  Thus,  the  mathematical 
procedures  of  these  analytical  solutions  are  very  complex  for  our  network.  Only  steady-state  results  are 
possible  for  these  systems.  Also,  it  is  very  difficult  to  obtain  estimates  of  parameters  other  than  mean 
values.  Because  of  economic  reasons  and  difficulties  creating  real  world  conditions,  it  is  almost 
impossible  to  exercise  the  systems  in  the  field,  either.  Thus,  to  answer  a  wide  variety  of  “what  if’ 
questions  is  a  major  issue.  Simulation  enables  us  to  analyze  different  policies  and  system  alternatives  in 
our  study.  Simulation  can  also  quantify  the  difference  between  the  alternative  systems  and  helps  to  see 
their  advantages  or  disadvantages. 

3.1.  Model  Development 

To  build  the  model  we  first  observe  the  system  and  the  interactions  among  its  various  components  and 
collect  data  on  its  behavior.  Then  we  construct  a  conceptual  model  (a  collection  of  assumptions  on  the 
components  and  the  structure  of  the  system,  plus  hypotheses  on  the  values  of  model  input  parameters)  by 
carefully  determining  the  level  of  details.  After  all,  we  translate  the  operational  model  into  the 
computerized  model.  The  stages  of  the  model  development  process  are  given  in  Figurel. 


REAL 

WORLD 

SYSTEM 

(ASSUMED 
SYSTEM 


Figure  1.  The  stages  of  model  development  process 


When  developing  a  simulation  model,  determining  the  correct  level  of  detail  for  the  model  is  very 
important.  The  simulation  model  should  have  enough  details  to  represent  the  real  world  system.  There  is 
always  a  trade  off  between  accuracy  and  cost  of  the  model  and  level  of  details.  Lack  of  details  usually 
causes  wrong  answers  to  the  questions,  while,  too  much  detail  requires  more  time  and  efforts,  longer 
simulation  runs,  and  it  is  more  likely  to  make  errors.  Also,  it  is  more  difficult  to  debug  and  make  changes. 


3.1.1.  Conceptual  Model 

Conceptualizing  a  model  is  one  of  the  important  phases  of  model  development.  A  conceptual  model 
provides  an  organized  way  for  an  analyst  to  document  the  system  of  interest.  We  create  conceptual  models 
of  these  real  world  systems  to  examine  the  essential  components  and  structures  of  the  real  world  systems 
under  consideration.  Then  the  basic  elements  of  this  simulation  model  are  determined  by  the  certain 
characteristics,  components  and  the  structure  of  the  assumed  system.  During  conceptualization,  we  gather 
data  about  the  systems,  and  then  we  construct  the  logical  model  (flowchart)  to  show  relationships  among 
the  elements  of  the  model.  Conceptual  model  contains  elements  of  the  real  system,  which  should  be 
included  in  our  model.  These  include  events,  entities,  attributes,  exogenous  variables,  endogenous 
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variables,  operational  rules,  initial  conditions  and  assumptions  of  the  system.  The  basic  elements  of  the 
proposed  simulation  model  is  given  below: 

Entities.  An  entity  is  an  object  of  an  interest  in  the  system,  which  requires  an  explicit  representation  in  the 
system.  In  our  system,  entities  are  voice  calls,  messages,  live  video  files  and  other  data  files. 

Attributes.  Attributes  are  the  characteristics  of  an  entity.  Our  attributes  are  source  node,  destination  node, 
source  RAP,  destination  RAP,  maximum  hop  number  and  call  duration. 

Events.  An  event  is  an  instantaneous  occurrence  that  changes  the  state  of  the  system.  The  events  of  the 
system  are  destruction  of  nodes,  call  request,  call  establishment  and  clear  request. 

Activities.  An  activity  is  a  time  period  in  which  the  state  of  an  entity  does  not  change.  The  activities  of  the 
system  are  call  establishment  and  data  transmission. 

Input  Variables.  Input  variables  are  number  of  MSTs,  number  of  PSTs,  number  of  RAPs,  velocity  of 
nodes,  direction  of  nodes,  weather  and  terrain  conditions,  call  duration. 

State  Variables.  State  variables  of  the  system  are  state  of  MSTs,  state  of  PSTs  and  state  of  RAPs. 

Performance  Measures.  Performance  measures  include  following:  Number  of  rejected  calls  because  of 
insufficient  data  channels,  number  of  rejected  calls  because  of  unreachable  destinations,  number  of 
terminated  calls  because  of  unreachable  destinations,  total  number  of  calls,  ratio  of  Terminated  Calls, 
average  message  delivery  time,  average  call  establishment  time,  unit  utilization,  channel  utilization,  ratio 
of  unreachable  destinations  (ROUD:  the  ratio  of  number  of  the  calls  rejected  since  the  destination  is  not  in 
the  coverage  area  of  allowed  number  of  relay  units  over  total  number  of  calls)  and  ratio  of  blocked  calls 
(ROBC:  the  ratio  of  number  of  rejected  calls  because  of  insufficient  radio  resources  over  total  number  of 
calls).  The  last  two  performance  measures  are  important,  since  as  these  ratios  get  higher,  the  users  of  the 
system  will  have  difficulties  to  establish  a  communication  link  with  the  destination  nodes,  even  in  some 
cases  they  cannot  communicate  with  some  of  them. 

We  have  also  made  some  assumptions  in  the  model.  These  are: 

•  All  units  are  synchronized  in  time. 

•  Every  unit  has  a  unique  identification  number,  which  is  known  by  other  units. 

•  All  links  are  bi-directional. 

•  Units  detect  the  existence  of  a  neighbor  or  a  link  failure  within  a  finite  time  by  a  link  layer 
protocol. 

•  Velocity  of  a  unit  is  uniformly  distributed  between  0  and  8  kilometers  per  hour. 

•  Units  cannot  go  out  of  the  region  defined  for  every  hour  of  simulation. 

•  The  lost  packets  over  a  link  are  transmitted  and  received  again  by  a  link  layer  protocol,  so  that 
transmission  is  completed  in  the  call  duration  time. 

•  Packets  sent  in  control  channels  are  received  correctly  by  the  neighbor  units  in  transmission  range 
of  the  source  node. 

•  There  is  no  electronic  attack  measure  of  the  enemy. 
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3.1.2.  Logical  Model 

Logical  model  shows  the  relationships  among  the  elements  of  the  model.  We  construct  the  logical  model 
of  the  messaging  system  of  a  brigade  via  flowcharts.  A  flowchart  is  a  pictorial  summary  of  the  flows  and 
decisions  that  comprise  a  process.  It  has  several  advantages  in  constructing  the  model  such  as  functioning 
as  a  communication  and  planning  tool,  providing  an  overview  of  the  system,  defining  roles,  demonstrating 
interrelationships  and  promoting  logical  accuracy. 

3.1.3.  Simulation  Model 

We  write  the  code  of  simulation  model  by  using  the  Arena  7.0  simulation  program  [3].  There  are  many 
simulation  packages  that  are  used  for  modeling  communications  networks.  Arena  software  is  a  general- 
purpose  simulation  language,  that  is,  it  can  also  be  used  for  modeling  manufacturing  systems,  for  combat 
modeling  or  for  modeling  communications  networks.  It  is  also  a  powerful  and  flexible  tool  in  creating 
animated  models  and  offers  reasonably  good  simulation  output  process.  The  major  advantage  of  general- 
purpose  languages  is  their  ability  to  model  almost  any  kind  of  communications  network,  regardless  of  its 
complexity.  Their  possible  drawbacks,  as  compared  to  some  simulators,  are  the  need  for  programming 
expertise  and  possibly  the  long  time  spent  coding  and  debugging  that  is  associated  with  modeling  complex 
networks  [7].  Hence,  to  develop  the  model  was  a  challenging  task  during  our  study. 

3.2.  Input  Data  Analysis 

The  communication  system  that  we  model  is  a  new  system  and  it  is  not  tried  in  a  war  condition  or  in  an 
exercise  that  we  know.  Hence,  it  is  not  possible  to  collect  required  input  data  for  our  system.  But,  in  a  data 
network,  it  seems  reasonable  to  assume  that  the  arrival  process  can  be  described  as  a  Poisson  process. 
Thus,  we  use  exponential  distribution  for  the  call  interarrival  times.  For  the  call  duration  times,  we  used 
uniform  distribution,  since  it  provides  a  good  approximation  when  it  is  known  that  the  service  time  is 
random,  but  no  information  is  available  about  the  distribution  [4].  We  obtain  the  parameters  of  the 
distribution  functions  by  interviewing  the  military  experts.  Some  of  the  data  points  are  taken  from  the 
army  field  manuals  that  are  written  according  to  the  war  experiences.  In  the  future  applications,  as  we 
gather  new  data  sets,  the  input  data  analysis  techniques  discussed  in  Law  and  Kelton  [5]  can  be  employed 
to  find  correct  distribution  functions  for  random  variables. 

3.3.  Model  Verification  and  Validation 

Verification  and  validation  is  one  of  the  most  important  stages  of  a  simulation  study,  since  any 
conclusions  derived  from  the  model  will  not  have  any  meaning  unless  the  model  verified  and  validated. 
We  verify  and  validate  our  model  by  using  the  following  techniques  and  considering  the  principles  of 
Balci  [6]  for  all  steps  of  our  study. 

3.3.1.  Verification  of  Model 

Model  verification  is  the  process  of  determining  that  a  model  implementation  accurately  represents  the 
developer’s  conceptual  description  and  specifications.  In  other  words,  by  using  verification  techniques  we 
will  check  the  translation  of  the  conceptual  model  into  a  correctly  working  program.  We  use  the  tools  such 
as  tracking,  debugging  and  animation  to  verify  the  model. 

3.3.2.  Validation  of  Model 

Model  validation  is  the  process  of  determining  the  degree  to  which  a  model  is  an  accurate  representation 
of  the  real  world  from  the  perspective  of  the  intended  uses  of  the  model  [8].  In  validation  process,  we 
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would  like  to  see  that  the  proposed  model  for  our  system  is  really  the  accurate  representation  of  the  real 
system.  Only  after  the  model  is  validated  the  evaluations  made  with  the  model  can  be  credible  and  correct. 
We  use  the  techniques  such  as  sensitivity  analysis,  face  validity  and  fault/failure  insertion  test  to  validate 
our  model.  The  results  are  presented  in  Table  1.  As  expected  the  model  produced  invalid  behaviours  for 
both  cases. 


Table  1.  Results  of  fault/failure  insertion  test 


Performance 

Measures 

Values  for 
Typical  Model 

Values  for  Fault 
Insertion  Test 

Values  for  Failure 
Insertion  Test 

ROUD 

0.0074 

0.0011 

0.082 

ROBC 

0.0106 

0.025 

0.379 

4.  DESIGN  AND  ANALYSIS  OF  EXPERIMENTS 

In  this  section,  we  model  messaging  system  of  a  model  brigade  in  an  attack  operation.  We  first  determine 
number  of  replications  needed  to  achieve  a  desired  accuracy  in  simulation  experiments.  Then  we  measure 
the  system  performance  and  finally  implement  factorial  design  to  explore  the  significant  factors  and  their 
effects.  We  begin  the  statistical  procedures  by  determining  number  of  replications  needed  to  achieve  a 
desired  accuracy  on  the  estimates  of  the  perfonnance  measures.  We  use  sequential  procedure  with  relative 
precision  criterion  to  determine  number  of  replications  [5].  The  specific  objective  of  the  procedure  is 
obtain  an  estimate  of  p  with  a  relative  error  of  y  (()<)'<  1 )  and  a  confidence  interval  of  100(1 -a)  percent. 
The  two-stage  procedure  is  as  follows: 

Step  1 .  Make  n0  replications  (more  than  two)  of  the  simulation  and  set  n  =  n0 


Step  2.  Compute  X(ri)  and  S(n,a )  where,  5(n,a)  =  tn  n  a/2 


S\n) 
V  n 


is  the  half-length  of  the  confidence 


interval. 


S^n^ct}  ,  — 

Step  3.  If  _ ’ —  <  y  ,  use  X{n)  as  the  point  estimate  of  //  and  stop.  This  ratio  is  an  estimate  of  the 


X{n) 


y 


actual  relative  error,  y  = -  is  the  adjusted  relative  error  to  get  an  actual  relative  error  of  y  .Else  make 

1  +  y 

one  more  replication  and  go  to  Step  2. 


The  two  main  performance  measures  that  we  will  evaluate  are  ROBC  and  ROUD.  We  choose  the  initial 
sample  size  as  10  and  y  =  0.10  for  both  of  the  performance  measures  and  simulate  the  system  for  one  day 
length.  The  averages  and  variances  for  each  performance  measure  are  presented  in  Table  2. 


Table  2.  The  averages  and  variances  for  each  performance  measure 


Performance 

Measure 

ROBC 

ROUD 

X(n) 

0.0106 

0.0074 

S\n ) 

3.32  E-06 

1.59  E-06 

We  find  that  we  need  to  make  at  least  10  replications  for  ROBC  and  12  replications  for  ROUD  to  achieve 
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the  desired  accuracy.  Then  we  decide  to  make  15  replications  of  simulation  model.  After  determining  the 
number  of  replications  to  achieve  the  desired  accuracy  we  construct  the  confidence  intervals  for  ROBC 
and  ROUD.  In  our  case  a  =0.05. 

4.1.  Evaluation  of  System  Performance 

To  evaluate  the  system  performance,  we  conduct  15  simulation  runs,  and  analyse  the  results.  The  values  of 
average  of  15  runs  for  different  various  measures  are  given  in  Table  3. 


Table  3.  Results  of  average  of  15  runs  for  performance  measures 


Performance  Measure 

Average 

Total  number  of  calls 

3215.7 

Number  of  blocked  calls 

34.2 

Number  of  blocked  messages 

15.67 

Number  of  blocked  voice  calls 

3.46 

Number  of  blocked  video  transmission 

9.13 

Number  of  blocked  other  data 

5.93 

Number  of  unreachable  destinations 

23.9 

Number  of  terminated  calls 

0.67 

Average  call  establishment  time 

1.91  sec. 

Average  call  duration  time 

47.71  sec. 

When  we  evaluate  the  system  performance,  it  seems  that  the  system  does  not  have  a  serious  problem. 
Approximately  one  percent  of  calls  are  blocked  because  of  insufficient  resources  that  are  an  acceptable 
value  for  a  communications  network  on  the  battlefield.  Also,  the  value  of  ratio  of  unreachable  destinations 
is  evaluated  as  in  good  standards.  While  investigating  the  results  of  simulation  runs,  we  see  that  the 
system  is  significantly  affected  by  live  video  transmission.  The  plot  of  ratio  of  blocked  calls  by  data  types 
is  presented  in  Figure  2. 
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Figure  2.  ROBC  values  for  different  types  of  data 

Since,  live  video  transmission  needs  an  important  part  of  resources  (24  data  channels),  over  nine  percent 
of  live  video  transmission  is  blocked.  Voice  calls  have  the  smallest  ROBC  value  since  this  type  of  data  use 
only  two  channels  of  system  resources.  Since  live  video  transmission  has  the  greatest  ROBC  value,  we 
examine  the  system  performance  in  the  absence  of  live  video  transmission  to  see  the  effect  of  this  type  of 


15-8 


RTO-M  P-MSG-022 


The  Modelling  and  Simulation  of  a  Messaging  System  of  a  Model  Brigade 


data  on  performance  measures.  We  see  that  all  the  messages  are  sent  to  their  destinations  without  any  type 
of  blocking  in  the  absence  of  live  video  transmission.  We  also  investigate  ROBC  values  for  different  types 
of  units.  The  results  of  ROBC  values  by  types  of  units  are  presented  in  Figure  3. 
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Figure  3.  ROBC  values  for  different  types  of  units 


The  reconnaissance  squad  has  the  greatest  value  of  ROBC.  The  second  greatest  value  belongs  to 
mechanized  infantry  and  armor  companies.  In  the  system,  only  these  units  transmit  live  video.  The 
mechanized  infantry  and  armor  battalions  are  the  third  in  terms  of  value  of  ROBC  since  they  realize  the 
greatest  data  transmission  in  the  system. 

4.3  2k  Factorial  Design 

To  study  the  effects  of  the  factors  on  performance  measures  and  the  interactions  between  factors,  we  use 
factorial  design.  A  special  type  of  factorial  design  is  2k  factorial  design,  which  is  widely  used  in 
experiments  involving  several  factors.  We  implement  21'  factorial  design  for  the  model  to  determine  the 
effects  and  possible  interactions  of  factors  on  system  performance  considering  performance  measures.  In 
our  study,  there  are  five  factors  under  consideration.  An  explanation  of  factors  and  their  levels  is  given 
below. 

Factor  A:  In  the  existing  system,  the  brigade  has  five  mechanized  infantry  battalions  and  two  armored 
battalions.  We  determine  the  high  level  as  a  typical  brigade  organization.  To  examine  the  effects  of 
different  number  of  users  on  the  performance  measures,  we  decrease  the  number  of  users  in  RAP-2  and 
RAP-3  by  removing  a  mechanized  infantry  battalion  from  RAP-2  and  an  armored  battalion  from  RAP-3  as 
the  low  level  of  factor. 

Factor  B:  At  high  level  of  Factor  B,  we  increment  the  arrival  rates  messages  twice  of  typical  conditions. 
Low  level  represents  normal  conditions. 

Factor  C:  At  the  low  level  of  the  factor,  the  units  move  at  a  speed  of  4  kph  and  the  brigade  moves  24 
kilometres  per  day.  At  the  high  level,  mobility  is  high.  Units  move  at  a  speed  of  1 6  kph,  and  the  brigade 
moves  72  kilometres  per  day. 

Factor  D:  In  bad  weather  and  terrain  conditions,  the  transmission  range  of  units  will  decrease.  We 
decrease  the  transmission  range  of  MSTs  and  RAPs  as  the  half  of  their  actual  range  at  the  low  level  of  the 
factor. 

Factor  E:  At  the  low  level  of  this  factor,  when  the  data  channels  are  insufficient  the  call  requests  are 
rejected.  At  high  level,  when  the  data  channels  are  insufficient,  the  call  requests  are  buffered,  and  if  the 
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data  channels  are  available,  the  call  request  is  confirmed.  The  timeout  values  for  request  are  15  seconds 
for  voice  calls  and  video  transmission  and  60  seconds  for  messages  and  other  data. 


4.3.1.  Implementation  of  ANOVA 

We  implement  analysis  of  variance  (ANOVA)  to  find  out  which  factors  and  interactions  have  significant 
effects  on  the  system  performance.  We  run  the  model  for  32  design  points.  To  achieve  independency,  we 
run  each  of  the  32  design  points  with  different  seeds  and  different  random  number  streams.  First,  we  check 
the  homogeneity  of  variances  and  normality  assumptions,  which  are  to  be  satisfied  to  implement  ANOVA. 
We  have  32  design  points,  and  we  test  the  following  hypothesis. 

Ho :  a,2  =  a\  =  cr32  = . =  <t322 

Hi:  Above  is  not  true  for  at  least  one  cr2 

To  check  homogeneity  of  variance  assumption,  we  applied  Bartlett’s  and  Levene’s  test.  These  tests  are 
widely  used  to  diagnose  the  inequality  of  variances.  The  result  of  Barlett’s  test  is  given  in  Table  4  and 
results  of  Levene’s  test  are  given  in  Table  5.  The  assumption  of  homogeneity  of  variances  is  satisfied  for 
ROUD  and  ROBC  in  both  tests. 


Table  4.  Bartlett’s  test  result  for  ROBC  and  ROUD 


Performance 

Measure 

ROBC 

ROUD 

Sp 

3.617  E-06 

3.272  E-06 

Q 

19.313 

18.073 

c 

1.0238 

1.0238 

X/ 

43.437 

40.647 

X  0.05,31 

45 

45 

Test  Result 

Do  not  reject 

Do  not  reject 

In  Levene’s  test,  a  low  significance  value  generally  less  than  0.05  indicates  that  the  variance  significantly 
differs  between  groups.  The  assumption  of  homogeneity  of  variances  is  satisfied  for  both  performance 
measures. 


Table  5.  Levene’s  test  results  for  ROBC  and  ROUD 


Performance 

Measure 

F 

dfl 

df2 

Significance 

Value 

Test  Result 

ROBC 

1.219 

31 

448 

0.197 

Do  not  reject 

ROUD 

1.007 

31 

448 

0.459 

Do  not  reject 

To  check  normality  assumption,  first,  we  compute  residuals  using  regression  model.  Then,  we  construct  a 
histogram  of  residuals.  If  the  normality  assumption  is  satisfied,  then  this  plot  should  look  like  a  sample 
from  a  normal  distribution  centered  at  zero.  We  also  construct  a  normal  probability  plot  of  the  residuals. 
Another  procedure  to  check  normality  is  to  construct  scatter  plots  of  residuals.  This  plot  of  residuals 
should  not  show  any  obvious  pattern.  We  also  check  scatter  plot  of  variances.  We  see  that  there  is  no 
obvious  patterns  or  structures  in  these  plots. 

Also,  note  that  appearance  of  a  moderate  departure  from  normality  does  not  necessarily  imply  a  serious 
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violation  of  the  assumptions.  Since  the  F  test  is  only  slightly  affected  from  moderate  departures  from 
normality,  we  can  say  that  the  analysis  of  variance  is  robust  to  the  normality  assumption.  But,  gross 
deviations  from  normality  require  further  analysis  [9]. 

4.4.  Evaluation  of  Main  Effect  and  Interaction  Effects  on  ROBC 

We  use  SPSS  software  package  to  implement  ANOVA.  Then,  we  plot  the  main  effect  and  interaction 
effects  diagrams  to  evaluate  the  results.  The  SPSS  output  of  ROBC  performance  measure  is  given  in 
Appendix  E.  There  are  three  significant  factors  and  four  two-way  interaction  effects  on  the  performance 
measure.  The  main  effect  diagram  is  shown  in  the  Figure  4. 


The  significant  factors  are  factor  A,  B  and  E.  Factor  E  has  an  effect  that  decrease  the  value  of  the 
performance  measure  while  the  other  significant  factors  have  increasing  effects.  When  a  user  has  a  buffer, 
if  there  is  not  sufficient  data  channel  to  confirm  the  call  request,  it  does  not  immediately  reject  the  call. 
The  call  request  is  buffered  during  15  seconds  for  voice  calls  and  video  transmission  and  60  seconds  for 
messages  and  other  data  files.  If  there  exist  sufficient  number  of  data  channels  in  this  period,  the  call  is 
confirmed.  Otherwise  call  is  blocked.  This  causes  a  significant  decrease  in  number  of  blocked  calls.  The 
effects  of  factor  A  and  B  cause  an  increase  in  the  value  of  ROBC,  since  the  data  channel  utilization  will 
increase  in  both  cases.  Factor  C  and  D  have  not  significant  effects  on  the  ROBC.  The  units  on  the 
battlefield  are  positioned  close  to  each  other  and  they  move  in  their  responsibility  area.  Hence,  mobility 
does  not  affect  the  distance  between  them  significantly.  Bad  weather  and  terrain  conditions  will  affect  the 
transmission  range,  but  this  decrease  in  the  transmission  range  will  not  affect  the  number  of  hops  from 
source  to  destination  significantly.  We  have  also  four  significant  two-way  interaction  effects.  These  are 
between  factors  A-B,  B-C,  A-E  and  B-E.  First  interaction  effect  is  between  factor  A  and  B.  Both  factors 
have  effects  that  increase  the  value  of  ROBC.  When  the  brigade  has  five  battalions,  utilization  of  data 
channels  increase.  If  we  increase  the  traffic  rate  while  the  data  channels  are  highly  utilized,  increase  in 
ROBC  will  be  more  significant.  Thus,  the  slope  of  the  performance  measure  when  one  factor  is  at  its  high 
level  is  more  than  the  slope  of  the  performance  measure  when  the  factor  is  at  its  low  level.  Another 
interaction  effect  is  between  factor  B  and  C.  Factor  B  has  an  increasing  effect  on  the  performance  measure 
and  factor  C  has  not  a  significant  effect.  The  other  interaction  is  between  factor  B  and  E.  The  factor  B  has 
an  increasing  effect  while  the  effect  of  factor  E  is  decreasing.  The  factor  E  has  a  more  significant  effect  on 
ROBC.  When  the  utilization  of  data  channels  is  high,  the  factor  E  affects  ROBC  more.  The  interaction 
between  factor  A  and  E  can  be  explained  in  a  similar  way  as  interaction  between  B  and  E.  The  results 
show  us  that  as  the  number  of  messages  increase  in  the  system,  the  system  robustness  goes  down.  Since 
the  distances  between  the  units  of  the  brigade  in  an  offensive  operation  are  not  long,  the  effect  of  mobility 
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is  not  significant.  But  as  the  distances  get  longer,  this  effect  will  increase. 

4.5.  Evaluation  of  Main  Effect  and  Interaction  Effect  on  ROUD 

We  plot  the  main  effect  and  interaction  effects  diagrams  of  ROUD  performance  measure  to  evaluate  the 
results.  There  are  three  significant  factors  on  the  performance  measure.  The  main  effect  diagram  is  shown 
in  the  Figure  5. 


The  significant  factors  are  factor  A,  C  and  D.  Factor  A  and  D  have  effects  that  decrease  the  value  of 
ROUD  while  factor  C  has  an  increasing  effect.  The  weather  and  terrain  conditions  are  the  most  significant 
factor.  Mobility  factor  is  more  significant  than  the  type  of  brigade.  As  the  mobility  increase,  the  distance 
between  the  source  and  destination  node  will  also  increase  such  that  the  destination  is  not  reachable  in 
allowed  number  of  hops.  The  other  significant  factor  is  the  type  of  brigade  that  has  a  decreasing  effect  on 
ROUD.  As  the  number  of  subscribers  of  the  same  RAP  increase,  the  network  will  have  a  more  connected 
structure.  The  more  connected  network  structure  will  cause  a  decrease  in  the  value  of  ROUD.  The  traffic 
rate  and  existence  of  buffer  is  not  significant  because  they  do  not  make  any  change  in  the  distance 
between  users.  The  only  significant  two  ways  interaction  effect  is  between  factor  A  and  D.  When  factor  D 
is  at  its  low  level,  the  effect  of  factor  A  is  more  significant. 


5.  CONCLUSIONS 

In  this  study  we  develop  a  simulation  model  for  a  messaging  system  of  a  model  brigade.  We  have  two 
main  performance  measures  under  interest  that  are  ROBC  and  ROUD.  We  determined  the  effects  of 
different  factors  on  performance  measures  and  finally  construct  different  scenarios  to  examine  the  effects 
of  different  types  of  operations  on  performance  measures.  When  we  evaluate  the  system,  the  system 
performs  well  for  all  performance  measures.  It  seems  that  the  system  does  not  have  a  serious  problem.  The 
multi-hop  capability  of  units  extends  the  connectivity  of  the  network.  The  effect  of  the  higher  usage  of 
multimedia  files  is  negative  on  the  system  performance.  Units  should  send  this  type  of  data,  when  the 
network  is  less  congested. 

We  perform  2/l  factorial  designs  to  determine  the  effects  of  factors  on  performance  measures  and 
implement  ANOVA  to  determine  the  factors  that  have  significant  effects  on  performance  measures.  The 
significant  factors  on  ROBC  are  type  of  brigade,  message  traffic  rate,  and  existence  of  buffer.  The  results 
show  us  that  as  the  number  of  messages  increase  in  the  system,  the  system  robustness  goes  down.  Since 
the  distances  between  the  units  of  the  brigade  in  an  offensive  operation  are  not  long,  the  effect  of  mobility 
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is  not  significant.  But  as  the  distances  get  longer,  this  effect  will  increase.  The  significant  factors  on 
ROUD  are  type  of  brigade,  mobility  and  weather  and  terrain  conditions.  Type  of  brigade  and  weather  and 
terrain  conditions  have  effects  that  decreases  the  value  of  ROUD  while  mobility  has  an  increasing  effect. 
The  weather  and  terrain  conditions  are  the  most  significant  factor.  The  only  two-way  interaction  effect  is 
between  type  of  brigade  and  weather  and  terrain  conditions.  As  the  number  of  units  in  the  same  area 
increase,  the  network  will  be  more  connected  because  of  the  multi-hop  capability  of  units.  The  distance 
between  units  is  an  important  factor  for  this  performance  measure. 
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ABSTRACT 

To  date,  legacy  simulations  of  all  operation  levels  have  not  dealt  with  the  C4ISR  aspects  of  the  battle 
space.  Nearly  all  of  these  simulations  assumed  either  perfect  C4ISR  capability  on  both  sides  or  employed 
some  unjustified  approaches  to  take  C4ISR  capabilities  of  the  opposing  forces  into  account.  These 
approaches  to  modeling  C4ISR  did  not  make  it  possible  to  evaluate  C4ISR  systems  and  their  contribution 
to  the  mission  effectiveness. 

Currently,  especially  developed  countries  are  well  aware  of  the  potential  contributions  of  robust  and 
integrated  C4ISR  systems  to  overall  military  effectiveness  and  working  on  concepts  like  Information 
Warfare,  Network  Centric  Warfare  and  etc.  Most  of  these  countries  are  spending  large  portions  of  their 
budgets  on  procuring  /  developing  C4ISR  systems.  C4ISR  systems  are  inherently  very  complex  and  as  a 
result  it  is  very  hard,  if  not  possible,  to  develop  architecture,  concept  and  tactics  with  pure  analytical 
approaches.  At  this  point,  simulation  seems  to  be  the  most  suitable  candidate  for  this  kind  of  C4ISR 
analysis. 

This  paper  will  present  a  detailed  description  of  the  Command,  Control,  Communication  and  Computer 
Analysis  Tool  (C4AT)  that  is  currently  being  developed  by  the  Turkish  General  Staff  Scientific  Decision 
Support  Center.  When  the  first  version  is  completed,  the  tool  will  be  capable  of  simulating  peace  time 
activities  of  the  strategic  and  operational  level  command  and  control  centers.  The  second  version  will  also 
have  the  ability  to  simulate  and  analyze  crisis  and  conflict  time  activities  of  the  similar  command  and 
control  centers. 

1.0  INTRODUCTION 

The  study  of  complex  systems  that  have  many  actors  and  their  interactions  often  becomes  too  complex  for 
a  mathematical  model.  Agent-based  modeling  is  a  tool  to  study  these  kind  of  systems.  The  tricky  part  of 
this  modeling  tool  is  to  specify  the  environment,  agent-knowledge  model  and  the  interactions  between  the 
agents. 

A  software  agent  can  be  defined  as  any  type  of  software  entity  that  fulfills  the  basic  concepts  of  agency. 
Ferber  defines  the  properties  of  a  software  agent  as  follows  [Ferber  1999]  : 

•  An  agent  is  capable  of  acting  and  modifying  its  environment 

•  An  agent  can  communicate  with  other  agents  in  the  environment 

•  An  agent  has  intentions 

•  An  agent  controls  some  local  resources 
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•  An  agent  is  capable  of  perceiving  its  environment  to  a  limited  extent 

•  An  agent  has  only  a  partial  representation  of  its  environment 

•  An  agent  possesses  skills  and  can  offer  services 

The  need  for  simulating  a  group  of  agents  in  an  environment  leads  to  the  development  of  Multi- Agent 
Systems  (MAS).  Weiss  gives  the  following  characteristics  of  multi-agent  environments  [Weiss  1999]: 
They  provide  a  basis  for  specifying  interaction  and  communication  protocols;  they  are  mostly  open  and 
have  no  centralized  designer;  they  contain  autonomous  and  distributed  agents  that  may  be  cooperative  or 
self-interested.  Instead  of  defining  MAS  characteristics,  Ferber  reports  elements  that  comprise  a  MAS. 
These  elements  are  environment,  objects,  agents,  relations,  operations,  and  operators.  Environment  is  a 
space  in  which  every  object  of  the  MAS  resides.  Everything  in  the  environment  is  an  object.  An  agent  is 
also  an  object  in  the  environment  that  satisfies  agency  requirements.  Relations  link  objects  to  each  other  in 
the  environment.  Operations  are  the  actions  that  agents  can  perform  in  order  to  modify  the  environment 
and  to  achieve  their  goals.  Operators  can  be  described  as  the  laws  of  the  environment.  Operators  are 
basically  the  reactions  of  the  environment  to  the  actions  taken  by  agents.  Constructing  a  MAS  requires 
detailed  models  of  these  elements. 

MAS  simulation  is  a  new  solution  to  the  problem  of  imitating  complex  adaptive  systems.  Axelrod 
describes  MAS  simulation  as  “a  way  of  doing  thought  experiments,”  the  goal  of  which  is  to  enrich  our 
understanding  of  fundamental  systems  [Axelrod  1997].  He  contents  that  the  goal  of  MAS  simulation  is  not 
to  find  exact  solutions  to  real  world  problems,  but  rather  to  provide  insight  into  complex  systems  that 
conventional  approaches  cannot  model.  Therefore,  modeling  every  aspect  of  the  system  is  unnecessary. 
Axelrod  proposes  the  famous  army  slogan,  “Keep  it  simple,  stupid”  to  the  MAS  simulation  designers. 
Otherwise,  the  change  in  the  outcome  of  the  simulation  cannot  be  linked  to  any  particular  variant  in  the 
simulation  and  hence  makes  simulation  useless.  However,  one  should  also  be  very  careful  in  deciding 
which  aspect  of  the  real  world  should  not  be  included  in  the  simulation.  Omitting  a  key  component  of  a 
system  from  the  simulation  may  result  in  meaningless,  undesired  outcomes. 

command  and  control  centers  are  complex  organizations  in  nature.  They  contain  many  co-operating  actors 
(agents),  each  having  different  personalities,  roles,  and  goals.  Within  these  organizations,  many  time 
critical  processes  take  place  in  parallel  which  makes  it  very  hard  to  keep  track  of  the  interactions  between 
the  agents.  These  interactions  are  also  highly  depended  on  the  work  load,  which  is  determined  by  the 
outer  organizations.  With  these  properties,  any  command  and  control  center  can  be  thought  as  a  multi 
agent  system. 

Since  it  is  too  hard,  if  not  impossible,  to  model  such  a  complex  system  with  conventional  modeling  and 
simulation  techniques,  agent-based  approach  has  been  chosen  to  study  command  and  control  centers,  and 
a  generic  agent-based  simulation  engine  is  implemented. 

Section  2  describes  the  generic  simulation  engine  and  the  methodology  for  creating  a  new  project.  Section 
3  deals  with  the  communication  devices  and  their  working  principles.  Section  4  introduces  the 
environment  design.  Section  5  presents  detailed  information  on  the  agent  architecture.  Section  6  is 
intended  to  demonstrate  a  scenario  in  execution.  Finally,  Section  7  gives  a  summary  of  the  study  and  its 
results. 


2.0  THE  SIMULATION  ENGINE 

In  order  to  implement  our  agent-based  tool  for  simulating  command  and  control  centers  (ComConCent), 
first  a  generic  simulation  engine  independent  of  the  tool  was  developed.  The  generic  simulation  engine  is 
actually  a  single  software  class  ( TBtnEngine ),  which  is  used  as  a  base  class  and  inherited  in  order  to  create 
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our  analysis  tool,  C4AT.  The  functions  of  the  TBtnEngine  is  as  follows: 

•  Enabling  creation  and  modification  of  the  project  environment  and  the  scenario, 

•  Managing  environment  and  scenario  files  (save  and  load  operations) 

•  Defining  scenario  agents  incuding  their  behavioral  characteristics  and  tasks  based  on  the 
developed  High  Level  Task  Management  Script  (HLTMS)  and  Behavioral  Transition  Networks 
(BTN)  architecture. 

•  Accepting  insertion  of  any  project  specific  resources  (  properties,  methods,  classes,  data,  etc.) 

•  Allowing  agents  to  access  all  the  resources  of  the  project  through  a  C-like  run-time  interpreter 
developed  within  the  scope  of  the  study. 

•  Running  scenario  with  a  selected  time  management  mode  (event  based,  real-time,  and  constant 
time  interval). 

As  mentioned  above,  TBtnEngine  can  be  customized  using  object  inheritance,  thus  new  projects  can  be 
created  by  just  over-writing  the  bold  lined  functions  depicted  in  Figure  1.  TBtnEngine  controls  the  whole 
simulation  activities  through  these  functions.  For  instance,  when  a  new  agent  needs  to  be  created,  the 
engine  calls  the  CreateAgentProc  function  (pointer)  to  let  creation  of  a  project  specific  agent  instance. 


class  TBtnEngine 

TBtnEngine 
virtual  ~  TBtnEngine 

[  TObjectBaseClass  *  includes,  TCreateAgent  CreateAgentProc  ) ; 

(  ); 

TCreateAgent  CreateAgentProc; 

virtual  void  SaveToStream 

virtual  void  LoadFromStream 

;  TStream  *  stream  ) ; 

’  TStream  *  stream  ) ; 

virtual  void  SimStarted 
virtual  void  SimStopped 
virtual  void  SimAdvanced 

virtual  bool  InLOS 

)  ; 

)  ; 

;  double  simTime,  double  deltaTime  ) ; 

’  TAgentBaseClass  *  agent,  TAgentBaseClass  *  target  ) ; 

void  SaveToFile 
void  LoadFromFile 

’  AnsiString  filename  ) ; 

’  AnsiString  filename  ) ; 

void  Start 
void  Pause 
void  Stop 
void  Advance 

) ; 

) ; 

) ; 

) ; 

TAgentBaseClass  *  AddAgent 
TAgentBaseClass  *  FindAgent 

); 

’  AnsiString  name,  int  *  index  =  NULL  )  ; 

Figure  1.  TBtnEngine  Class  Interface:  new  projects  can  be  created  by  customizing  the  bold  lined 

functions 


The  critical  point  in  customizing  the  engine  is  to  use  TObjectBaseClass  as  a  base  class  to  all  the  new 
classes.  This  base  class  enables  registering  any  variables  and  functions  in  real  time  to  let  the  run-time 
interpreter  access  project  resources.  To  extend  the  flexibilty  of  customation,  TBtnEngine  and  all  of  its  sub¬ 
classes  are  also  inherited  from  this  class.  With  the  customized  engine,  C4AT,  the  geographical  location  of 
the  scenario  can  be  set,  the  ComConCent  buildings  including  their  interior  can  be  designed,  the 
communication  devices  can  be  introduced  and  the  agents  can  be  defined.  The  C4AT  architecture  and  its 
class  definition  are  shown  in  Figures  2  and  3  respectively. 


RTO-MP-MSG-022 


16-3 


Modeling  Command  &  Control  Centers 


ORGANIZATION 


C4AT  Simulation  Engine  Inherited  From  TBtnEngine 


Agents 


Com.  Device  Links 
Assigned  Node  Link 


BTN  Root 


Type  Definitions, 
Parameters, 
Properties, 
Methods, 
Events, 
Transitions 


HLTMS 


Parallel  Sub-BTNs 


Buildings 


Floors 


Nodes 


Com. Device  Links  - 
■  Agent  Links 


Arcs 


Regions 


Connections 


Com.  Devices 


Types 


Phone, 

Wireless, 

Fax, 

Computer, 

Television, 

Radio 


■  Assigned  Node  Link 
Carrying  Agent  Link 


Figure  2.  The  general  architecture  of  the  C4AT 


class  TC4ATEngine  :  public 

TBtnEngine 

TComDevices  *  ComDevices; 
TBuildingSet  *  BuildingSet; 

TC4ATEngine 

(  TOb jectBaseClass  *  includes,  TCreateAgent  createAgentProc  ) ; 

virtual  ~  TC4ATEngine 

(  ) ; 

virtual  void  SaveToStream 

(  TStream  *  stream  ) ; 

virtual  void  LoadFromStream 

(  TStream  *  stream  ) ; 

Figure  3.  C4AT  Simulation  Engine  Class  :  The  bold  lined  objects  are  extension  of  the  project, 
and  the  rest  are  functions  modified  in  order  to  customize  the  engine 


3.0  DEFINING  THE  COMMUNICATION  DEVICES 

The  communication  devices  that  are  employed  in  command  and  control  centers  can  be  categorized  as: 
phone,  radio,  fax,  computer,  and  multimedia  (television,  radio,  newspaper,  etc.).  Since,  speed  has 
generally  higher  priority  than  information  security  in  peace  time  operations,  the  phone  is  the  most 
preferred  communication  device  in  such  operations. 

Consequently,  we  started  the  development  of  communication  devices  with  the  phone.  For  the  time  being, 
the  first  version  of  the  telephone  communication  framework  is  completed.  In  this  framework,  the  phone  is 
designed  to  be  in  one  of  the  following  states:  available,  waiting  for  dial  tone,  ready  to  dial,  calling, 
connected,  busy,  disconnected  or  ringing. 

The  agents  are  designed  in  such  a  way  that  they  can  detect  if  a  phone  is  in-use,  if  not,  they  can  pick  up  the 
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phone,  wait  for  the  dial  tone,  dial  the  number  and  take  different  actions  depending  on  the  communication 
state  (calling,  connected,  busy  or  disconnected)  and  finally  hang  up  the  phone. 

An  agent  can  only  use  three  kinds  of  phones  categorized  by  their  ownership:  the  ones  he  carries  on  (e.g. 
cellular  phones),  the  ones  he  is  responsible  for  (e.g.  at  home,  at  the  office),  and  the  ones  that  are  owned  by 
his  group  members.  When  a  phone  rings,  the  agents  around  the  phone  can  hear  the  ring.  If  it  is  one  of  the 
phones  he  carries  on  or  he  is  responsible  for,  he  immediately  tries  to  pick  up  the  phone.  If  it  is  owned  by 
one  of  his  group  members,  then  he  waits  for  a  short  period  of  time  and  if  no  one  picks  it  up,  he  tries  to  do 
it,  and  else  no  reaction  is  performed. 


4.0  DESIGNING  THE  ENVIRONMENT 

The  simulation  environment  consists  of  a  set  of  buildings  and  their  interior.  The  location  of  each  building 
is  described  by  its  geographical  coordinate  in  lattitude  and  longitude.  Following  the  definition  of  the 
location,  the  building  images  are  automatically  displayed  on  the  screen  if  corresponding  data  exists  in  the 
environment  database.  A  sample  building  exterior  is  illustrated  in  Figure  4. 


Figure  4.  A  building  exterior  visualized  with  two  different  zoom  levels 


In  order  to  create  building  models,  a  building  editor  is  developed.  This  editor  is  capable  of  designing 
buildings  by  creating  each  floor  and  their  connections  with  other  floors.  Floors  contain  nodes  (connectors, 
tables,  chairs,  etc.),  arcs  (walls,  windows,  doors,  etc.),  regions  (room  floors,  roofs,  etc.)  and  connections 
(walking  routes,  relational  links,  etc.).  A  sample  building  interior  design  is  demonstrated  in  Figure  5. 
Every  object  in  the  environment  is  positioned  on  one  of  the  nodes.  Connections  are  used  for  defining 
possible  routes  that  could  be  used  for  navigation  and  specifying  relations  between  objects.  For  example, 
when  an  agent  percepts  that  a  phone  is  ringing,  he  first  tries  to  go  to  a  neighbor  node  of  the  table  on  which 
the  phone  is  located  by  searching  the  connections  to  the  table. 
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Figure  5.  A  building  interior :  The  buildings  are  designed  as  set  of  floors. 


5.0  DEFINING  THE  AGENTS 

The  behaviors  of  the  agents  are  modeled  using  Behavioral  Transition  Networks  (BTN)  and  a  sub-feature 
defined  within  BTN  structure  called  High  Level  Task  Management  Script  (HLTMS).  BTNs  [Houlette 
2000]  are  firstly  introduced  by  game  developers  to  increase  practical  aspects  of  defining  behaviors.  Later 
on,  they  became  more  common  and  used  in  many  other  fields.  In  fact,  BTNs  are  just  a  specialized 
approach  based  on  State  Transition  Diagrams  and  Harel  Diagrams  (statecharts)  [Harel  1988,  Ghezzi  1991, 
Rosenblum  1994,  Budgen  1994],  and  defined  using  nodes  and  state  transitions  between  nodes.  Nodes 
may  possess  sub-nodes,  resulting  a  type  of  hierarchy. 


A  modified  version  of  BTN  framework  is  developed  for  TBtnEngine.  This  framework  has  some  additional 
features  such  as  parallel  executable  sub-BTNs  and  a  HLTMS.  General  architecture  of  our  BTN  framework 
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is  illustrated  in  Figure  6. 

Each  BTN  node  has  its  type  definitions,  in-going  transition  parameters,  out-going  transitions  (in  a 
hierarchical  case  based  structure),  properties,  methods,  events,  and  a  HLTMS.  BTN  nodes  are  activated, 
executed  and  deactivated  by  transitions,  HLTMS  and  events:  on  enter,  on  leave,  on  message  and  on 
process.  Each  event  is  a  script  which  is  executed  by  the  run-time  interpreter.  All  the  events  but  on  process, 
are  executed  from  start  to  end  at  once.  Execution  of  on  process  events  can  be  interrupted  by  using  wait  or 
breakcode  statements  defined  in  the  script. 


HLTMS 

definition 

window 


action  BTN 
node 


parallel 
executable 
sub-BTN  set 


Figure  7.  A  root  BTN  sample  for  agent  behavior  modeling 


Figure  8.  “CALL  BY  PHONE”  action  BTN  (left),  transitions  of  “Try  To  Pick  Up  The  Phone”  (right) 


Each  agent  has  a  set  of  behaviors  assigned  to  him,  which  are  defined  in  a  single  BTN  node  (root  BTN). 
Therefore,  customizing  that  BTN  node  (defining  HLTMS,  adding  sub-BTNs,  etc.)  also  changes  the 
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behavioral  characteristics  of  the  agent.  In  our  agent  design,  first  level  BTNs,  the  ones  directly  owned  by 
root  BTN,  are  generally  used  for  action  modeling  such  as  calling  by  phone,  going  to  a  location,  etc.  A  root 
BTN  and  an  action  BTN  are  demonstrated  in  Figures  7  and  8  respectively.  As  seen  in  Figure  7,  there  are 
no  transition  arcs  between  action  nodes,  because  actions  are  fired  by  HLTMS. 

HLTMS  is  actually  a  hierarchically  defined  script,  the  statements  of  which  can  be  executed  sequentially  or 
in  parallel.  Some  of  HLTMS  statements  and  their  descriptions  can  be  viewed  in  Table  1. 


Table  1.  Some  of  the  HLTMS  statements 


Statement 

Description 

STARTPAR 

Starts  a  parallel  execution  (starts  executing  sub-script  under  STARTPAR  in  parallel) 

CANCELPAR 

Terminates  a  parallel  execution 

WAIT 

Waits  for  a  specified  time  period 

LET 

Assigns  a  value  to  a  variable.  If  variable  is  not  defined,  it  is  created 

ADDINFO 

Inserts  an  information/data  item  into  BTN  node 

ADDINFORM 

Inserts  an  information  message  into  a  parallel  execution 

ADDTASK 

Inserts  a  task  into  a  parallel  execution 

REMOVETASK 

Removes  the  active  task  of  a  parallel  execution 

DELAYTASK 

Delays  execution  of  the  active  task  of  a  parallel  execution 

ISAY 

Sends  a  voice  message  to  an  agent  or  object  (phone) 

IDO 

Triggers  an  action 

DORESULT 

Captures  the  result  of  an  action 

LISTEN 

Starts  listening  for  perception  messages,  information  messages  and  tasks 

I  HEAR 

Used  inside  a  LISTEN  statement.  Enables  receiving  voice  perception  messages 

I  INFORMED 

Used  inside  a  LISTEN  statement.  Enables  receiving  information  messages 

I  SELECT 

Used  inside  a  LISTEN  statement.  Enables  selecting  from  tasks.  The  task  with  highest 
priority  is  always  selected. 

LOUT 

Backtracks  to  the  start  of  a  specified  LISTEN  statement 

An  example  HLTMS  for  responding  a  phone  call  is  illustrated  in  Figure  9.  In  the  sample,  the  execution  is 
started  from  the  very  first  line.  When  a  STARTPAR  statement  is  reached,  a  parallel  execution  for  the  sub¬ 
statements  called  “Conversation  Manager”  is  started.  After  that,  the  execution  continues  and  reaches  to 
another  STARTPAR,  which  starts  another  parallel  execution  called  “Task  Manager”.  And  finally  the 
execution  reaches  to  a  LISTEN  block  that  contains  a  single  WAIT  statement,  which  causes  an  infinite  loop. 
When  “Conversation  Manager”  is  executed,  it  starts  listening  for  voice  messages.  If  a  phone  rings,  the 
agent  gets  a  voice  message  informing  him  that  the  phone  is  ringing.  This  causes  the  addition  of  a 
“Respond  Phone”  task  to  the  parallel  execution  called  “Task  Manager”.  When  “Task  Manager”  is 
executed,  it  starts  listening  for  tasks.  When  it  encounters  a  “Respond  Phone”  task,  it  starts  executing  the 
sub-statements  of  the  task.  The  agent  first  identifies  the  phone  to  see  if  he  has  right  to  pick  it  up.  If  so,  he 
finds  the  location  of  the  phone,  goes  to  that  location  and  picks  up  the  phone.  If  the  connection  is 
established,  the  agent  says  hello  to  the  remote  side  and  waits  for  a  reply.  If  he  gets  the  reply,  he  insert  an 
information  message  to  “Conversation  Manager”  to  inform  the  starting  of  the  conversation  and  waits  until 
the  phone  conversation  is  terminated.  Then,  the  “Conversation  Manager”  captures  the  information 
message  and  guides  the  conversation.  For  simplicity,  the  conversation  part  is  skipped.  After  the 
termination  of  conversation,  the  conversation  manager  inserts  an  information  message  to  “Task  Manager” 
informing  that  the  conversation  is  over.  In  this  case  the  “Task  Manager”  hangs  up  the  phone  and  starts 
waiting  for  another  task. 
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B  "►  STARTPAR  Conversation  Manager 
B  4?  USTEN  Listening!  1 

El  CE3  I  HEAR  Phone  Ringing  (  )  [  phone  ] 

ADDTASK  [  ]  RESPOND  PHONE  ( phone )  [  Task  Manager  ]  [  SimTime  ]  [  -1  ]  [  -1  ]  [  ]  [  LOCALv{phone}.State()  ==  "Ringing*'  ]  [  LOCALv{phone}.State()  !=  "Ringing"  ]  [  p5  ] 
STARTPAR  Task  Manager 
i  B  4$  LISTEN  V/aiting  [  ] 

6  ipi  I  SELECT  RESPOND  PHONE  ( phone ) 

B  g  I  DO  [  0  ]  IDENTIFY  PHONE  (  phone  ) 

B-J  DORESULT  HAS  RIGHT  TO  RESPOND  (category) 

I  B  IS  I  DO  [  0  ]  FIND  PHONE  LOCATION  ( phone ) 

B  @  DORESULT  FOUND  (location) 

I  B  I  DO  [0]  GO  TO  LOCATION  ( location,  "Slow" ) 

B  0H  DORESULT  REACHED  (  ) 

A  U  I  DO  ( 0  ]  PICK  UP  PHONE  ( phone ) 

B  0§  DORESULT  CONNECTED  (  ) 

:  |H|  I  SAY  Hello  I  am  ...  (  )  [  phone  ]  [  3  ] 

;  B  4$  LISTEN  [  phone  ) 

B  CE3  I  HEAR  Hello  I  am  calling  from ...  (  )  [  ] 

U>  ADD  INFORM  Conversation  Started  (  phone  )  [  Conversation  Manager  ] 

b  4>  listen  [  ] 

B  #  I  INFORMED  Conversation  Ended  (  ) 

X  REMOVETASK  (  ] 

B  Qg  I  DO  ( 0 1  HANG  UP  PHONE  ( phone ) 

t"j  LOUT  Listening  [  Conversation  Manager ) 

1";  LOUT  Waiting  [  ] 

i~H  DORESULT  NOT  RINGING  ANY  MORE  (  ) 

X  REMOVETASK  [  ] 
i"i  LOUT  Waiting!  1 

6  U  DORESULT  NOT  REACHED  ( reason ) 

X  REMOVETASK!  1 
r)  LOUT  Waiting!  1 
B  05  DORESULT  NOT  FOUND (  ) 

X  REMOVETASK  (  ] 

;  I-]  LOUT  Waiting!  1 

&  DORESULT  NOT  HAVE  RIGHT  TO  RESPOND  (  ) 

X  REMOVETASK  [  ] 

1":  LOUT  Waiting  [  ] 

B  4s  LISTEN  I  1 
©  WAIT  60 


Figure  9.  A  sample  HLTMS  for  responding  a  phone  call 


In  order  to  avoid  implementing  complex  perception  algorithms,  which  are  beyond  the  scope  of  this  study, 
we  assumed  that  the  agents  can  perceive  (hear  and  see)  any  object  that  is  at  the  same  floor  and  within  10 
meters  range. 

Following  the  development  of  voice  and  visual  perception  mechanism,  we  were  able  to  form  a 
methodology  for  task  distribution  among  agents.  Although  there  are  many  complex  ways  to  introduce 
collaboration  among  agents  [Axelrod  1997,  Feber  1999,  Ercetin  2001],  we  used  a  simple  but  effective 
model,  which  reflects  nature  of  command  and  control  hierarchy.  An  agent  informed  of  a  task  (event, 
request,  order)  generates  a  set  of  sub-tasks  to  meet  the  requirements  of  the  main-task.  Following  task 
decomposition,  additional  sub-tasks  for  task  distribution  management  are  inserted.  For  instance,  if  the  task 
is  an  event,  the  agent  generates  sub-tasks  of  the  event  and  an  additional  task  for  reporting  to  the  superior. 
If  the  agent  could  not  manage  to  inform  his  superior,  he  starts  doing  tasks  that  are  not  strictly  depended  on 
the  completion  of  informing  the  superior.  When  he  manages  to  give  the  report  to  the  superior,  the  sub¬ 
tasks  not  completed  yet  are  fully  canceled,  because  because  they  will  be  distributed  by  the  superior.  Then 
the  superior  generates  a  list  of  sub-tasks  for  himself  and  for  his  sub-ordinates,  and  distributes  the  sub-tasks 
to  his  sub-ordinates  considering  the  work  load. 

The  path  planning  of  agents  for  navigation  is  another  challenging  problem  to  be  solved.  Path  planning  is 
defined  as  searching  for  a  set  of  state  transitions  to  reach  to  a  goal  location  from  an  initial  location.  It  is 
cetegorized  in  to  two:  off-line  [Deloura  2000]  and  real-time  [Undeger  2001a,  Undeger  2001b]  path 
planning.  Off-line  path  planning  has  the  advantage  of  generating  high  quality  routes,  but  takes  much  CPU 
time  and  not  suitable  for  highly  dynamic  environments.  On  the  contrary,  real-time  path  planning 
algorithms  give  poor  solution  quality,  but  is  highly  interactive  and  very  adaptive  to  changing  conditions. 
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The  technique  employed  in  our  study  is  off-line  path  search  through  the  connection  graph,  which  is 
discribed  in  Section  4. 


6.0  RUNNING  THE  SCENARIO 

Once  the  behaviors  and  tasks  of  agents  are  modeled,  the  next  step  is  to  run  the  scenario.  This  function  is 
directly  supported  by  TBtnEngine.  The  TBtnEngine  allows  selection  of  time  management  metodology  and 
simulation  time  multiplier.  There  are  three  main  time  management  modes:  event  based,  real-time  and 
constant  time  interval.  In  the  event-based  time  management  mode,  the  events  are  tracked  in  the  order  that 
they  will  occur  and  the  simulation  is  advanced  to  the  nearest  one.  Therefore,  the  scenario  is  run  as  fast  as 
possible  in  this  mode.  This  mode  is  currently  under  development.  The  second  mode  is  real-time,  in  which 
the  time  is  advanced  in  parallel  with  the  real-time  (or  a  multiplier  of  real-time).  In  this  mode,  there  is  a 
possibility  that  the  advance  of  a  single  step  of  the  simulation  will  take  more  time  than  desired.  For  this 
reason,  this  mode  is  divided  into  three  sub  modes:  unlimited  time  steps,  constant  time  steps,  upper 
bounded  time  steps.  If  unlimited  time  steps  mode  is  used,  the  simulation  time  steps  continue  until  all  the 
related  code  is  executed.  If  constant  time  steps  mode  is  preferred,  the  execution  is  interrupted  and  passed 
to  the  next  step  when  the  specified  constant  time  is  exceeded,  else  a  delay  is  inserted  to  reach  the  specified 
constant  time.  In  upper  bounded  time  steps  mode,  the  execution  is  interrupted  and  passed  to  the  next  step 
if  specified  constant  time  is  exceeded.  The  last  time  management  mode,  constant  time  interval,  is 
generally  used  in  debug  mode,  which  ignores  real-time  and  advances  simulation  time  with  constant  time 
step,  no  matter  how  much  time  the  step  actually  takes. 

After  starting  the  simulation,  the  simulation  state  can  be  observed  on  visualization  window  and  messages 
are  printed  on  the  message  window.  The  environment,  the  location  and  body  posture  of  agents,  the  state  of 
devices  and  the  messages  exchanged  are  all  shown  on  visualization  window.  The  messages  (BTN 
execution  messages,  HLTMS  execution  messages,  and  run-time  interpreter  messages)  are  printed  to  the 
message  window.  The  visualization  and  message  windows  are  shown  in  Figure  10. 


a  phone 
ringing 


simulation 

visualization 

window 


message 

window 


Figure  10.  A  snapshot  of  the  simulation  in  execution 
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7.0  CONCLUSION 

In  this  paper,  we  have  proposed  a  simulation  framework  and  a  simulation  tool  for  modeling  command  and 
control  centers.  First,  we  have  started  with  the  definition  and  properties  of  software  agents,  and  clearly 
stated  the  reasons  for  developing  our  framework  on  top  of  agent  based  systems.  Later,  the  generic 
simulation  engine  designed  to  realize  the  framework,  and  the  customized  engine  for  C4AT  have  been 
presented  in  detail.  We  have  mostly  focused  on  our  agent-based  system,  which  employs  Behavioral 
Transition  Networks  and  a  newly  proposed  approach  called  High  Level  Task  Management  Script.  For 
C4AT  analysis  toolkit,  a  communication  framework  and  an  environment  design  is  developed  and  a  sample 
scenario  is  generated.  The  first  version  of  our  implementation  has  given  promising  results  for  modeling  a 
larger  scenario  that  covers  all  the  functions  of  a  ComConCent.  Thus,  we  are  currently  studying  on  the  tool 
for  defining  new  agent  behaviors  and  tasks  to  improve  the  system. 
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1.  INTRODUCTION 

Command,  control,  communication  and  intelligence  (C3I)  systems  as  well  as  simulation  systems  belong  to 
the  class  of  model-based  information  systems.  This  is  obvious  in  the  case  of  simulations,  which  are  always 
based  on  models.  But  C3I  systems,  too,  have  to  be  based  on  models  of  the  corresponding  real  world 
processes  in  order  to  manage  the  tremendous  complexity  of  military  systems.  The  latter  becomes 
immediately  clear  when  thinking  of  terrain  representation  in  form  of  military  maps,  which  are  a  perfect 
example  for  reliable  models.  However,  since  model  designers  necessarily  abstract  and  simplify  reality 
according  to  their  own  perception  and  conceptions,  models  can  significantly  differ  in  several  aspects. 
Experiments  with  the  high  resolution  combat  simulation  system  COSIMAC  (developed  at  the  Institute  for 
Applied  Systems  Science  and  Operations  Research  (IASFOR)  at  the  University  of  the  Federal  Armed 
Forces  Munich,  Department  of  Computer  Science)  and  some  modules  implementing  basic  C3I 
functionality  (command  and  control  modules)  have  shown  that  there  are  some  essential  preconditions  for 
coupling  such  model  based  information  systems.  Our  results  indicate  that  technical  and  syntactic 
preconditions  (addressed  by  HLA  and  ATCCIS,  for  example),  which  have  been  in  the  focus  of  interest  for 
almost  a  decade,  are  not  sufficient  to  guarantee  a  successful  interaction.  The  crucial  tasks  are  to  ensure  that 
syntactical  structures  are  attributed  with  the  same  meanings  in  all  involved  models  and  that  the  same 
actions  are  triggered  by  identical  orders  and  reports.  These  findings  have  been  confirmed  during  a  study 
we  performed  for  the  German  Armed  Forces  addressing  the  standardization  of  command  and  control 
components  for  different  Army  simulation  systems.  As  a  consequence  of  the  importance  of  meanings  and 
triggered  actions  we  have  chosen  a  linguistic  approach  to  understand  the  problems  of  interoperability, 
which  is  based  on  the  idea  of  successful  communication  between  models  /  model  users.  That  might  seem  a 
bit  strange  at  first  sight,  but  regarded  from  the  perspective  of  the  model  designer,  the  coupling  of  models  is 
in  fact  a  sophisticated  kind  of  communication  with  his  counterpart. 

In  linguistics  one  generally  presupposes  the  existence  of  a  technical  communication  channel  (which  is  so 
important  in  computer  science)  and  concentrates  on  the  three  semiotic  aspects  of  language  which  are 
syntax,  semantics  and  pragmatics.  Linguistics  provide  a  perfect  framework  for  investigations  into  the 
meaning  of  interactions,  since  the  whole  point  of  setting  up  a  theory  of  semantics  and  pragmatics  is  to 
provide  a  systematic  account  of  the  nature  of  meaning.  Communication  is  successful  if  and  only  if  sender 
and  receiver  have  common  knowledge  on  all  semiotic  aspects.  Based  on  our  experiments,  this  paper 
discusses  several  examples  of  failed  coupling  at  the  level  of  semantics  and  pragmatics.  Generalizing  these 
results  we  conclude  that  there  are  at  least  four  compulsory  preconditions  (1-4)  for  C3I/M&S 
interoperability  and  one  desirable  precondition  (5),  by  name: 
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(1)  Automatically  processible  data  (syntactical  standards) 

(2)  Standardized  algorithms  (for  data  fusion  and  aggregation) 

(3)  Similar  or  at  least  compatible  model  development  approaches 

(4)  Collated  triggering  of  actions 

(5)  Standardized  GUI  and  uniform  SW  ergonomics. 

Since  the  mere  presentation  of  coupling  problems  stemming  from  a  limited  amount  of  models  would  be 
too  anecdotic  and  idiosyncratic  to  be  convincing,  the  paper  first  introduces  a  general  framework  (sections 
2  -  5)  in  which  the  examples  presented  in  chapter  7  fit  as  illustrations  of  the  basic  ideas.  Section  6 
provides  the  reader  (non-insider)  with  some  fundamental  information  about  ground  combat  simulation 
systems. 


2.  MODEL  BASED  INFORMATION  PROCESSING  SYSTEMS 

From  a  general  point  of  view  information  processing  systems  can  be  distinguished  into  direct  and 
intermediate  control  information  systems  (see  Figure  1):  Most  of  the  (artificial)  information  processing 
systems  used  today  are  embedded  into  real  systems  in  which  they  operate  as  control  units.  Their  task  is  to 
ensure  that  the  state  transition  of  the  real  system  stays  within  a  given  trajectory.  Such  information 
processing  systems  exert  direct  control  over  the  system  they  are  part  of  (ps  -function  in  Figure  1). 
Examples  for  this  kind  of  information  systems  are  electronic  devices  like  anti-lock  braking  systems  or 
electronic  traction  control  systems  in  cars.  On  the  other  hand  there  are  information  processing  systems  that 
do  not  manipulate  the  real  system  states  directly.  One  possible  reason  for  this  is  that  in  these  systems  the 
space  of  possible  state  is  much  to  great  to  be  held  under  control  directly.  Via  abstraction  and  idealization 
(cp-function  in  Figure  1)  a  model  of  the  real  system  is  created.  Within  this  model  one  tries  to  achieve 
control  over  the  dynamics  of  the  assumed  states  (ZM,  and  not  Zs).  In  general,  this  is  done  by  postulating 
causal  dependencies  between  different  states.  After  execution  of  the  model  (pM-fu  notion)  it  is  necessary  to 
“retranslate”  from  ZM  to  Zs  (vp-function).  Now  it  is  possible  to  check  in  the  real  system  whether  the 
predictions  of  the  model  are  valid  ore  not.  If  they  are,  it  is  assumed  that  M  is  a  helpful  model  of  the  system 
S  and  \|/*pM*cp  is  regarded  to  be  a  good  substitute  for  ps. 


Figure  1:  Direct  and  intermediate  control  of  dynamics  in  systems  and  models 
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It  is  obvious  that  all  simulations  are  examples  of  model  based  information  processing  systems.  Combat 
simulation  systems  are  almost  perfect  instances  of  this  class.  But  C3I  systems  too,  have  to  be  regarded  as 
model  based.  Starting  with  the  company  level  and  intensifying  above  it,  military  command  is  based  on 
models  of  the  real  combat  situation.  The  direct  processing  of  observations  can  only  be  the  foundation  of 
combat  control  on  the  weapon  system  and  (to  a  certain  extent)  platoon  level.  Working  with  tactical 
symbols  on  terrain  maps  is  as  much  model  based  as  simulation. 


3.  MODELS  AND  THE  NEED  FOR  COMMUNICATION 

Whenever  models  A  and  B  of  systems  A  and  B  are  combined,  it  is  necessary  to  ensure  that  both  models 
share  a  common  conceptual  picture  C  of  the  supersystem  C  (see  Figure  2). 


Figure  2:  Models,  communication  and  validation 


Whereas  it  is  clear  that  the  supersystem  C  has  to  be  a  superset  of  A  and  B  (at  least  if  one  does  not 
deliberately  omit  aspects  of  the  real  world  modelled  in  A  or  B),  it  is  not  self-evident  that  the  common 
conceptual  model  C  is  likewise  only  a  superset  of  A  and  B.  In  fact,  in  most  cases  it  is  necessary  to  start 
with  the  intersection  set  of  A  and  B  and  extend  or  adjust  it  in  order  to  create  a  common  conceptual  model. 
As  an  example  let  us  consider  two  different  ground  combat  simulation  models  and  their  terrain 
representation.  The  supersystem  terrain  T(C)  has  to  be  a  superset  of  the  real  terrains  T(A)  and  T(B) 
modelled  in  A  and  B.  The  exact  definition  of  this  superset  should  not  be  a  challenging  problem  even  if 
T(A)  and  T(B)  are  completely  separated  and  we  have  to  define  an  additional  connecting  “corridor”. 
Unfortunately,  the  models  of  the  terrains  T(A)  and  T(B)  can  differ  so  much  from  each  other  that  even  if 
T(A)  and  T(B)  are  identical,  a  common  terrain  model  T(C)  is  extremely  hard  to  develop.  Let  us  assume 
that  T(A)  is  a  vector  model  and  T(B)  a  grid  model.  There  is  no  common  conceptual  model  for  these  two 
types  of  terrain  representation.  One  has  to  give  up  one  of  them  or  integrate  both  approaches  into  both 
systems.  Even  with  two  grid  models  serious  problem  can  occur  if  T(A)  and  T(B)  do  not  distinguish 
between  the  same  terrain  types  (forest,  urban,  open  terrain,  water,  etc.)  or  do  not  use  the  same  algorithms 
to  compute  trafficability  values  from  terrain  type,  slope  and  weather  conditions.  Using  the  formalism 
introduced  in  the  previous  chapter,  the  problem  can  be  stated  as  follows:  It  is  relatively  easy  to  combine 
two  system  state  sets  ZS1  and  ZS2  but  in  order  to  combine  two  model  state  sets  ZM1  and  ZM2,  the  different 
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abstraction  and  idealization  functions  cp1  and  cp2  (and  subsequently  pM1  and  |3M2  and  also  vp  and  \|/2>  have  to 
be  reconciled.  Whereas  set  theory  provides  powerful  means  for  the  first  task,  there  are  no  general  methods 
for  the  second  one,  since  abstraction  and  idealization  are  in  themselves  not  approachable  by  formalization. 
Consequently,  finding  a  common  conceptual  model  for  two  models  developed  from  different  persons  X 
and  Y  requires  intensive  communication  between  X  and  Y  about  cp1,  cp2,  pM1,  pM2  ,  vp1  and  vp2.  Despite  this 
challenge  it  is  very  assuring  that  the  basis  for  validation,  the  real  supersystem  C  is  generally  much  less 
disputable  than  C.  Thus,  checking  whether  the  coupling  of  the  models  was  successful  or  not  normally  has 
a  sound  foundation  (essential  for  validation).  Reconsidering  our  example,  one  can  easily  prove  if  a  vehicle 
movement  possible  in  your  coupled  model  would  have  been  possible  in  the  real  terrain. 


4.  A  LINGUISTIC  PERSPECTIVE  ON  MODEL  COMMUNICATION 

After  realizing  that  personal  communication  is  almost  inevitable  in  every  model  coupling  project  it 
becomes  essential  to  ensure  successful  communication.  Unfortunately,  there  exists  no  universal  formal 
language  that  could  grasp  the  whole  variety  of  abstraction  and  idealization  possibilities.  Thus,  at  least 
some  part  of  the  communication  process  between  the  modellers  will  be  natural  language  communication. 
The  special  branch  of  science  that  deals  with  successful  natural  language  communication  is  linguistics, 
which  differentiates  syntax,  semantics  and  pragmatics  of  an  utterance  in  language.  Since  most  people  are 
familiar  with  syntax  and  semantics  but  not  with  the  linguistic  concept  of  pragmatics  a  short  description 
may  be  helpful.  In  the  semiotic  trichotomy  developed  by  Charles  Morris,  Rudolph  Carnap,  and  C.  S. 
Peirce  in  the  1930s,  syntax  addresses  the  formal  relations  of  signs  to  one  another,  semantics  the  relation  of 
signs  to  what  they  denote,  and  pragmatics  the  relation  of  signs  to  their  users  and  interpreters  [1-3].  The 
central  rationale  for  pragmatics  is  that  sentence  meaning  (semantics)  in  natural  languages  vastly 
underdetermines  speaker’s  meaning  (intentions).  The  goal  of  pragmatics  is  to  explain  how  the  gap 
between  sentence  meaning  and  speaker’s  meaning  is  bridged  [4]. 

In  “linguistics  words”  (which  sometimes  seem  a  little  bit  convoluted),  pragmatic  information  concerns 
facts  relevant  to  making  sense  of  a  speaker's  utterance  of  a  sentence  (or  other  expression).  “The  hearer 
thereby  seeks  to  identify  the  speaker's  intention  in  making  the  utterance.  In  effect  the  hearer  seeks  to 
explain  the  fact  that  the  speaker  said  what  he  said,  in  the  way  he  said  it”  [5].  Because  the  intention  is 
communicative,  the  hearer's  task  of  identifying  it  is  driven  partly  by  the  assumption  that  the  speaker 
intends  him  to  do  this.  The  speaker  succeeds  in  communicating  if  the  hearer  identifies  his  intention  in  this 
way,  for  communicative  intentions  are  intentions  whose  "fulfilment  consists  in  their  recognition"  [6].  In 
other  and  much  simpler  words,  pragmatics  is  concerned  with  whatever  information  is  relevant,  over  and 
above  the  linguistic  properties  of  a  sentence,  to  understanding  its  utterance  [4].  It  should  be  mentioned  that 
even  Noam  Chomsky,  the  world’s  most  famous  and  influential  linguist  has  stated  that  “a  general  linguistic 
theory  must  incorporate  pragmatics  as  a  central  and  crucial  component”  [7]. 

As  an  example  consider  a  mountain  walk  of  an  experienced  climber  and  his  friend,  who  has  always  stayed 
in  flat  land.  During  the  walk  the  climber  shouts  “Stone”  and  expects  his  friend  to  seek  for  shelter. 
Unfortunately,  his  friend  doesn’t  even  raise  a  hand.  On  which  communication  level  occurred  the  error? 
We  can  assume  that  the  flatlander  heard  what  his  friend  said  (physical  transmission),  understood  the 
phoneme  “stone”  and  mentally  translated  it  into  the  correct  word  “stone”  (syntactic  level)  and  knew  what 
a  stone  is  (extensional  meaning  of  the  word,  semantic  level).  Hence  the  fatal  error  must  have  occurred  on 
the  pragmatic  level  as  an  failure  of  communicating  the  demand  of  action. 

It  is  obvious  that  the  line  between  semantics  and  pragmatics  cannot  be  absolutely  definite  and  that  some 
aspects  of  contextual  information  and  other  connotation  could  be  placed  into  the  semantic  bucket,  too.  (In 
the  example,  one  could  argue  that  the  semantic  of  the  word  “stone”  in  the  context  of  mountain  hiking  has 
to  be  extended.)  But  in  general  it  is  not  recommended  to  extend  the  borders  of  semantics,  because  it 
quickly  leads  to  person  dependent  ambiguity  in  semantic  definitions  (What  if  a  geologist  shouts  stone 
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during  a  mountain  walk?  Is  he  delighted  or  terrified?). 

However,  taking  the  nature  of  pragmatics  into  consideration,  it  is  no  surprise  that  it  has  been  omitted  in 
computer  and  many  other  sciences.  The  general  guideline  in  all  natural  and  technical  sciences  is  to  reduce 
subjective  factors  down  to  zero.  Hence  scientists  from  this  research  areas  seek  to  find  or  define  a 
pragmatics-free  (context,  connotation  and  especially  individual  opinion  free)  experimental  system. 
Unfortunately,  that  approach  has  strong  limitations  whenever  human  behaviour  and  communication  have 
to  be  regarded.  To  a  certain  extent  developing  models  for  complex  dynamic  systems  is  always  a  subjective 
endeavour,  especially  when  taking  into  consideration  the  different  purposes,  scales,  user  modes  and 
resolutions  of  models  of  such  systems,  the  degrees  of  freedom  within  each  of  these  aspects  and  the 
necessity  to  tailor  each  model  to  fit  the  purpose. 

So  far  the  linguistic  aspect  of  pragmatics  has  been  emphasised.  The  following  sections  changes  the  focus 
to  the  relationship  between  models  and  pragmatics.  As  an  introduction  to  this  relationship  consider  the 
definition  of  semiotic  qualities  of  conceptual  models  (see  Table  1)  given  by  [8]. 


Table  1 :  Definition  of  semiotic  qualities  of  conceptual  models  (Lindland  et  al.  1994) 


Syntactic  quality 

The  degree  of  correspondence  between  a  conceptual  model  and  its  representation. 

Semantic  quality 

The  degree  of  correspondence  between  the  conceptual  model  and  the  real  world. 

Pragmatic  quality 

The  degree  of  correspondence  between  the  conceptual  model  and  its  (individual) 
interpretation. 

One  of  the  central  dogmas  of  modem  computer  science  is  the  demand  for  unambiguous  programs  that  can 
be  used  without  any  additional  context  information  (information  hiding).  Especially  for  component- 
based  software  architectures  this  requirement  is  said  to  be  essential.  Taking  this  dogma  literally  implies 
that  documentation  of  programs  mustn’t  be  essential  for  model  understanding  and  application  but  only 
(extremely)  helpful.  Ideally  the  program/module  itself  (as  a  sequence  of  statements  in  a  programming 
language)  should  contain  the  whole  meaning/sense  of  the  underlying  (conceptual)  model. 

I  do  not  doubt  that  from  the  perspective  of  software  engineering  this  dogma  is  completely  justified.  There 
actually  is  a  huge  amount  of  software  that  fulfils  this  black-box  criteria.  However,  as  far  as  I  can  see,  these 
programmes  are  of  a  very  fine  granularity,  and  very  often  monofunctional.  The  simplicity  of  these 
components  in  terms  of  degrees  of  freedom  is  the  reason  why  the  black-box  approach  works.  However,  to 
base  a  general  hierarchy  of  domain  specific  components  -  that  finally  would  lead  to  complex 
multifunctional  modules  -  on  a  black-box  architecture  is  most  probably  an  illusion  of  current  software 
engineering.  In  complex  military,  economic  or  logistic  simulation  systems  the  code  vastly 
underdetermines  the  modeller’s  ideas  and  intentions.  Therefore,  model  documentation  in  natural 
language  and  additional  verbal  communication,  despite  all  their  disadvantages  of  ambiguity  and 
connotations,  are  essential  parts  of  the  interaction  among  model  developers  and  users. 


5.  THE  PROBLEM  OF  HIDDEN  ASSUMPTIONS 

The  hard  part  of  developing  simulation  systems  of  complex  dynamic  systems  is  not  code  generation  but 
appropriate  modelling  which  is  mainly  abstracting  and  idealizing.  If  all  abstraction  and  idealization  a 
modeller  has  used  in  building  a  model  were  easily  discemable  or  well  documented,  it  would  be  possible  - 
in  terms  of  the  framework  introduced  in  chapters  2  and  3  -  to  exactly  define  and  understand  the  cp-  ,  pM 
and  \|/-functions  underlying  the  model.  Unfortunately,  almost  every  modeller  uses  assumptions  which  are 
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not  documented  and  hard  to  reengineer  from  the  executable  model  if  one  does  not  know  what  to  look  for. 
In  general,  one  gets  to  know  about  hidden  assumptions  the  hard  way:  the  model-federation  produces 
nonsense  and  it  is  extremely  difficult  to  explain  it.  Naturally,  it  would  always  be  possible  to  make  a 
special  assumption  transparent.  The  problem  is,  that  in  the  modelling  of  complex  systems  there  are  so 
many  assumptions  involved  that  completeness  can  hardly  be  assured.  In  addition,  there  are  assumptions 
which  are  taken  for  granted  and  therefore  not  documented.  But  “self  evident  facts”  are  sometimes  quite 
disputable. 

Something  that  is  often  hidden  in  the  description  of  ground  combat  simulation  systems  is  the  scope  of  the 
perceived  situation.  Every  unit  and  every  command  level  has  a  perceived  situation,  which  differs  from  the 
real  situation  according  to  their  current  information  respectively  information  deficits.  In  reality,  this 
“picture  of  the  battlefield”  is  convoluted  mix  of  own  perceptions,  messages,  orders,  situation  updates  from 
higher  and  lower  echelons,  adjacent  units  and  even  civilian  information  sources.  It  is  extremely  difficult  to 
keep  all  this  pictures  consistent.  Therefore,  there  is  always  a  scope  of  the  perceived  situation  of  a  unit 
which  denotes  which  and  how  many  other  units  currently  share  a  consistent  variant  of  it.  Because  of  its 
complexity  the  real  development  and  updating  process  of  the  perceived  situation  is  simplified  within  the 
simulation  systems.  How  this  simplification  is  done  depends  on  many  factors,  especially  purpose  and 
resolution  of  the  simulation  system.  When  we  tried  to  find  it  out  for  the  combat  simulation  systems  listed 
in  the  next  chapter,  not  one  model  documentation  was  sufficient  and  I  venture  to  doubt  that  all  the 
modellers  of  these  systems  were  fully  aware  of  the  problem. 

It  may  be  a  subjective  opinion,  but  I  am  absolutely  convinced  that  it  is  impossible  to  reduce  hidden 
assumptions  in  models  of  complex  dynamic  systems  down  to  zero.  As  a  consequence  there  will  always  be 
the  need  for  an  intensive  test  and  adjustment  phase  after  a  technically  successful  coupling  of  such  models. 


6.  GROUND  COMBAT  SIMULATION  SYSTEMS  AND  C3I  SYSTEMS 

Over  more  than  two  decades  scientists  at  our  Institute  (IASFOR)  have  analysed  ground  combat  simulation 
systems  used  in  the  German  and  other  armies  (for  example:  JANUS,  HORUS,  GESI/SIRA,  PAPST, 
KORA,  IRIS  [9-12]  and  designed  and  implemented  own  simulation  systems  (see  below).  The  level  of 
complexity  of  these  models  reaches  from  simplified  test  simulation  systems  and  relatively  simple 
simulations  based  upon  cellular  automata  (ZEGA  and  ZELGAT  [13])  up  to  full  scope  aggregated  land 
battle  models  (KOSMOS  [14])  and  high  resolution  ground  combat  models  (BASIS  [15]),  COSIMAC-P, 
COSIMAC-WS  [13]),  which  are  in  terms  of  system  theory  [16]  extremely  complex.  In  addition,  we  have 
recently  compared  three  of  these  systems  (GESI,  HORUS  and  our  own  model  COSIMAC)  in  a  study.  The 
goal  of  this  study  was  to  assess  the  feasibility  of  standardized  command  and  control  (C&C)  modules  for 
high  resolution  combat  simulation  systems.  The  study  was  also  part  of  the  preparing  efforts  towards  a  new 
German  ground  combat  simulations  system  (“SimSys  Einsatz  Heer”),  which  is  intended  to  be  integrated 
into  the  new  German  C3I  environment.  Before  discussing  the  results  of  this  study,  a  short  introduction  to 
ground  combat  simulation  systems  is  given. 

Ground  combat  simulation  systems  (GCSS)  are  a  very  heterogeneous  class  of  models  ([13],  [17]), 
nevertheless  they  all  share  some  fundamental  parts.  Every  GCSS  has  to  model  the  following  aspects  of 
combat: 

1 .  terrain  and  environmental  representation, 

2.  movement, 

3.  attrition, 

4.  transportation  (at  least  of  ammunition), 
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5.  communication  and 

6.  reconnaissance. 

Generally,  GCSS  are  discrete  event  simulations  based  upon  an  event  queue.  The  GCSS  mentioned  above 
aren’t  real  time  simulations,  anyway  internal  time  management  is  essential.  If  the  GCSS  is  used  for 
analysis  in  a  closed  simulation  it  is  necessary  to  add 

7.  command  and  control  modelling, 

which  shouldn’t  be  a  part  of  the  central  simulator  -  for  reasons  explained  in  [13]. 

The  major  distinctions  between  the  models,  beside  different  purposes  (acquisition,  decision  support, 
analyses,  training),  scopes  and  user  modes  (closed  simulation  or  interactive),  is  their  level  of  resolution: 
the  level  of  detail  at  which  the  real  world  system  and  its  behaviour  is  modelled.  Referring  to  [18]  and  [19] 
resolution  in  combat  simulation  systems  has  six  “components”: 

1 .  temporal  scale, 

2.  spatial  scale, 

3.  processes, 

4.  entities, 

5.  attributes  and 

6.  dependencies. 

This  classification  is  arguable,  but  useful  to  illustrate  the  degrees  of  freedom  for  the  modelling.  It  has  been 
shown  (see  for  example  [18])  that  it  is  far  from  trivial  to  ensure  consistency  between  models  of  different 
resolution. 

In  terms  of  the  theoretical  framework  introduced  in  section  2  different  purposes,  scopes,  user  modes  and 
resolutions  all  tend  to  increase  the  deviations  between  the  cp-functions  and  consequently  between  the  |3M- 
functions  of  two  models.  Thus,  even  with  completely  congruent  real  systems  A  and  B  (C  =  A  =  B) 
deviations  between  the  models  A  and  B  can  be  too  great  to  find  a  satisfying  common  model  C. 

The  development  of  command  and  control  (C&C)  modules  for  GCSS  is  not  only  the  precondition  to 
reduce  the  amount  of  interactive  operators  in  command  post  exercises,  it  is  also  a  precondition  for  using 
GCSS  as  decision  support  tools.  Moreover,  it  is  essential  to  realize  that  the  integration  of  GCSS  into  C31 
systems  will  only  be  successful,  if  the  C&C-modules  in  the  simulations  operate  on  the  same  principles  as 
the  automatism  applied  within  the  C31  system.  Otherwise,  the  simulation  of  courses  of  action  in  advance 
would  be  very  dubious.  As  an  example  consider  the  problem  of  data  fusion.  The  same  algorithms  that 
process  (connect,  condense,  countercheck  etc.)  real  messages  in  C31  systems  have  to  be  applied  within  the 
simulation  in  advance  in  order  to  keep  its  situation  update  consistent. 


7.  ESSENTIAL  PRECONDITIONS  FOR  SUCCESSFUL  COUPLING  OF  MODEL 
BASED  INFORMTION  SYSTEMS 

With  the  basic  considerations  presented  in  the  previous  sections  it  is  now  possible  to  highlight  the  results 
of  the  research  at  our  institute  and  to  establish  the  essential  preconditions  for  successful  coupling  of  model 
based  information  systems.  In  the  following  it  should  be  reminded  that  the  conclusions  presented  here  are 
drawn  from  projects  within  the  simulation  domain.  It  has  to  be  admitted  too,  that  the  expertise  of  our 
institutes  (1ASFOR  and  IT1S)  covers  more  of  this  domain  than  of  the  traditional  Command,  Control, 
Communications,  Computers,  Intelligence,  Surveillance,  and  Reconnaissance  (C41SR)  domain. 
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7.1  Technical  aspects 

We  have  coupled  different  versions  of  our  own  COS1MAC  combat  simulation  systems  via  the  HLA, 
CORBA  and  a  simple  self-made  TCP/IP  interface  within  a  local  area  network.  Although  all  of  these 
solutions  had  some  drawbacks,  most  of  the  basic  technical  functionality  for  interoperation  could  be 
provided.  There  are  major  differences  between  these  solutions  when  it  comes  to  additional  services 
(authorisation,  time  management,  security  etc.),  flexibility  and  maintainability,  but  these  differences  also 
show  that  different  approaches  can  do  the  job.  So  far,  there  is  no  technical  framework  for  interoperation 
that  comprises  all  advantages  and  avoids  all  drawbacks  -  and  maybe  such  a  framework  will  never  exist. 
But  the  reassuring  result  of  our  own  research  is  that  most  of  the  problems  with  imperfect  technical 
architectures  are  surmountable.  Therefore,  if  there  is  any  real  problem  for  coupling  simulations  and  C31 
systems  at  the  technical  level,  it  will  be  the  problem  of  unification  on  the  basis  of  a  not  disputed 
standardisation. 

7.2  Syntactic  aspects 

The  first  precondition  for  coupling  model  based  information  systems  are  automatically  processible  data 
(terrain,  weapon  systems,  personal,  organisational,  tactics  etc.)  in  the  very  straightforward  sense  of 
standardized  syntactic  structures  that  may  lead  to  a  formal  military  language.  The  range  of  the  standard 
determines  the  range  of  easy  interoperation.  Thus,  NATO-wide  standards  are  preferable.  The  Land 
Command  and  Control  Information  Exchange  Data  Model  (LC21EDM)  was  an  important  step  in  that 
direction.  Without  a  common  syntax  the  coupling  of  simulations  and  C3I  systems  is  hardly  thinkable, 
since  syntactic  transformations  between  different  models  are  much  too  cumbersome  to  be  feasible  within  a 
multinational  environment.  The  challenge  on  this  level  is  put  by  general  drawbacks  of  all  formal 
languages  in  comparison  to  natural  languages.  First,  whereas  there  are  many  different  personal  incentives 
to  learn  a  foreign  natural  language,  the  use  of  a  formal  language  has  to  be  enforced.  Second,  no  formal 
language  can  capture  to  whole  expressiveness  of  a  natural  language.  Third,  most  of  the  difficulties  of 
misunderstandings  in  natural  languages  occur  on  the  pragmatic  level  of  communication.  Such 
misinterpretations  of  persons  you  use  a  language  can  happen  with  formal  languages  as  well.  Formality 
could  therefore  evoke  fallacious  trust. 

7.3  Semantic  aspects 

1  have  addressed  technical  and  syntactic  issues  only  briefly  because  there  is  so  much  other  work  done  in 
this  fields  and  1  have  to  admit  that  we  did  not  find  out  something  really  new  in  our  studies  for  these  levels. 
On  the  semantic  level,  in  contrast,  there  are  some  challenges  which  have  been  underestimated.  It  is  self- 
evident,  that  the  semantic  meanings  of  syntactic  structures  have  to  be  defined  according  to  common  use  or 
a  predefined  ontology.  In  general,  that  leads  to  a  kind  of  glossary  or  lexicon,  attributing  meanings  to 
character  strings.  During  the  efforts  to  integrate  command  and  control  modules  into  our  GCSS  we  realized 
that  such  a  lexicographic  summary  is  not  sufficient  to  guarantee  consistent  interoperation.  What  is  needed 
in  addition  are  standardized  algorithms  for  the  modelling  of  elementary  processes  like  attrition,  movement, 
data  fusion,  reconnaissance  and  communication.  In  order  to  explain  this  need,  an  illustrative  example 
might  be  helpful.  In  high  resolution  GCSS  it  is  necessary  to  model  reconnaissance  of  individual  combat 
vehicles  like  tanks  and  AFVs  (Armoured  fighting  vehicle).  This  can  be  done  with  regularly  “glimpses  “  or 
sector  scans,  with  global  detection  probabilities  or,  in  grid  models,  with  individual  terrain  cell  checks,  to 
name  just  a  few  possibilities  [17].  The  algorithms  behind  these  methods  lead  to  different  perceived 
situations,  since  detection  of  enemy  entities  will  not  occur  at  the  same  simulation  time.  However, 
perceived  situations  are  the  most  important  information  for  any  command  and  control  module.  Hence,  the 
reconnaissance  algorithm  influences  the  course  of  action  chosen  from  the  C&C  module.  A  module  devised 
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in  the  context  of  a  “glimpses”  model  is  therefore  not  directly  applicable  to  a  cell  check  model,  even  if  all 
messages  and  orders  the  C&C  module  gets  are  standardized  in  both  models,  or  with  other  words,  even  if  a 
standardized  interface  between  high  resolution  GCSS  and  additional  C&C  modules  exists.  One  can  easily 
transfer  this  example  to  the  problem  of  data  fusion  which  has  to  be  solved  both  in  simulation  systems  and 
C41SR  systems.  Different  fusion  algorithms  will  lead  to  different  estimates  of  the  situation.  A  simulation 
in  advance  using  its  own  data  fusion  algorithm  would  differ  from  the  real  course  of  action  perceived  after 
using  the  C31  data  fusion  algorithm  even  if  the  initial  situation  would  evolve  as  predicted.  Using  our 
theoretical  model,  the  problem  can  be  simplified  into  the  following  consideration:  With  a  static  lexicon  of 
standardized  terms  only  the  cp-functions  of  the  model  building  process  are  addressed.  The  dynamic 
processing  of  model  states  via  the  pM-functions  (algorithms)  remains  largely  unconsidered. 

On  the  other  hand  there  are  even  examples  that  consistent  cp-functions  cannot  be  guaranteed  only  with 
semantic  lexicons.  A  perfect  example  are  deterministic  and  stochastic  models  based  on  otherwise  identical 
representations.  Let  us  first  assume  that  two  simulation  systems  have  to  interoperate.  One  system  uses 
deterministic  parameters  and  the  other  determines  averages  from  a  certain  amount  of  stochastic  simulation 
runs.  It  is  very  well  known,  that  the  value  of  averages  highly  depends  on  the  underlying  distribution.  Any 
discrete  distribution  similar  to  the  continuous  probability  density  function  sketched  in  figure  3  would  be 
an  extreme  counterexample  for  the  use  of  averages. 


Figure  13:  Sketch  of  a  double  peak  probability  density  function  (PDF) 

If  the  stochastic  simulation  provides  the  deterministic  simulation  with  the  results  of  its  stochastic  runs  in 
the  form  of  such  an  average,  further  simulations  within  the  deterministic  model  are  almost  useless.  The 
same  would  hold  true  if  we  replace  the  deterministic  simulation  with  a  deterministic  C3I  system. 
Stochastic  and  deterministic  models  of  a  system  are  the  result  of  two  different  cp-functions,  which  are  not 
always  compatible  without  further  considerations  (about  variance  for  example).  Similar  problems  occur,  if 
discrete  and  continuous  or  event  and  process  driven  or  descriptive  and  predicting  models  are  connected.  It 
is  possible  to  couple  such  models  in  a  sensible,  purpose-driven  way,  but  only  with  adjustments  that  go  far 
beyond  even  a  sophisticated  glossary.  Consequently,  a  third  essential  precondition  for  coupling  model 
based  information  systems  are  similar  or  at  least  compatible  model  development  approaches. 

7.4  Pragmatic  aspects 

Pragmatic  aspects  of  interoperation  deal  with  the  actions  (state  transitions)  triggered  within  a  person  or 
any  other  information  processing  system  after  receiving,  decoding  and  semantically  understanding  a 
transmitted  information.  We  are  all  familiar  with  the  problem  of  the  huge  variety  of  possible  actions  and 
state  transitions  a  human  being  possess  in  a  communication.  In  order  to  be  successful  in  triggering  the 
desired  actions  or  state  transitions  in  the  receiver  the  human  sender  (speaker  or  writer)  has  to  take  into 
account  the  probably  different  attitudes,  beliefs,  physical  skills,  mental  capacities,  physical  and  emotional 
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constitutions,  social  and  cultural  backgrounds  of  his  counterparts.  In  general  this  is  done  unconsciously  as 
a  consequence  of  lifelong  learning.  Nevertheless,  most  of  the  unsuccessful  communications  between 
humans  occur  on  the  pragmatic  level.  The  very  reason  for  this  problem  is  that  it  is  relatively  easy  to  define 
the  semantic  meaning  of  a  word  or  sentence,  but  impossible  to  find  a  general  agreement  on  the  pragmatic 
influence  factors  attitude,  belief  etc. 

It  may  seem  that  this  problem  has  little  to  do  with  the  challenge  of  coupling  artificial  model  based 
information  systems  like  simulation  or  C31  systems.  Unfortunately,  as  has  been  shown  in  chapter  3  and  4, 
the  coupling  of  models  always  involves  human  communication  problems.  Therefore  it  should  be  expected 
that  errors  on  the  pragmatic  level  can  be  found  whenever  model  driven  information  systems  are  coupled. 
That  is  exactly  what  we  find  out.  I  do  not  want  to  discredit  any  of  the  models  mentioned  in  chapter  6 
except  our  own.  Thus,  I  am  not  going  to  use  these  model  names  in  the  following  examples. 

The  most  striking  examples  of  different  pragmatics  in  GCSS  we  found  in  command  and  control  modules. 
The  variety  of  possible  actions  and  state  transitions  triggered  from  an  “immediately  attack  objective  Z” 
order  given  to  different  C&C  module  is  impressive,  even  in  the  very  homogeneous  context  of  the 
COS1MAC  GCSS.  Different  programmers  (within  the  COS1MAC  project  all  programmers  where  active 
officers,  too)  assume  different  state  transitions  according  to  their  mental  picture  of  reality.  The  first  variety 
has  been  introduced  by  the  evaluation  of  the  term  “immediately”.  The  range  of  possible  and  actually 
realized  pragmatic  interpretations  spans  from  ’’abandoning  all  other  tasks”  and  “immediately”  start 
moving  with  available  unit  members  at  maximum  speed,  to  the  assembly  of  scattered  unit  members  and 
regrouping,  followed  by  a  movement  optimisation  based  on  speed  and  coverage. 

A  similar  problem  has  been  the  exact  state  transition  after  reaching  the  objective.  Most  COS1MAC 
programmers  (modellers!)  stopped  the  attacking  units  after  reaching  the  objective  and  deployed  them 
within  a  predefined  area  in  order  to  establish  an  all-around  defence.  However,  some  implemented  a  kind 
of  opportunity  function,  allowing  the  attacking  units  to  progress,  if  (a)  inferior  enemy  units  could  be 
destroyed  or  (b)  tactical  localities  could  be  seized.  In  general,  the  challenge  of  such  flexible  modules 
(mission-types  tactics)  is  to  ensure  that  the  higher  commanders  intent  (presumable  the  part  of  an  order 
which  defies  formalisation  the  most!)  is  always  taken  into  account. 

Which  behaviour  is  adequate  depends  on  circumstances  and  reflects  to  a  certain  extent  the  degree  of 
freedom  a  human  decision  maker  has  in  the  same  situation.  A  further  refinement  of  the  models  would  have 
been  necessary  to  overcome  this  problem.  However,  according  to  the  abstraction  and  idealization  level 
chosen  for  the  model  there  is  always  a  limit  for  such  extensions,  especially  in  rule-driven  modules 
(consistency!).  Additionally,  the  pragmatic  problems  tend  to  increase  with  higher  resolution,  since  more 
idiosyncrasies  of  terrain,  situation  and  mission  have  to  be  regarded. 

These  findings  which  have  been  first  realized  during  the  development  of  C&C  modules  for  the  GCSS 
COSIMAC,  have  been  strongly  supported  by  research  on  other  GCSS  of  similar  resolution  (HORUS, 
GESI).  Even  if  syntactic  and  semantic  inconsistencies  could  be  overcome,  pragmatic  issues  would  impede 
many  interesting  and  sensible  interoperations.  Details  of  this  research  can  be  found  in  [20]. 

It  is  essential  to  realize  that  inconsistency  problems  like  those  mentioned  above  are  not  consequences  of 
bad  modelling  but  consequences  of  the  modelling  of  complex  dynamic  systems  in  itself. 

Moreover,  during  efforts  to  integrate  the  human  factor  “willingness  to  take  risks”  in  the  GCSS  COSIMAC 
we  realized  that  the  variety  of  possible,  but  unfortunately  inconsistent  interpretations  can  only  be  curbed 
by  extremely  simplifying  assumptions  which  have  little  to  do  with  reality. 

What  all  of  these  examples  clearly  show  is,  that  the  actions  triggered  within  a  GCSS  after  receiving  a 
semantically  well  defined  message  or  order  can  significantly  and  inconsistently  differ.  Thus,  even  if  we 
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have  eliminated  all  ambiguities  through  unequivocal  semantic  definitions  model  coupling  can  still  fail. 
Fortunately,  for  most  of  the  examples  mentioned  above  it  is  possible  to  fix  a  kind  of  reference  model  with 
standard  actions  and  state  transitions  -  which  is  the  fourth  essential  precondition  of  coupling  model  based 
information  systems. 

The  last  aspect  of  interoperation  addressed  in  this  paper  is  theoretically  less  compulsory  than  the  previous 
ones  but  maybe  of  equal  importance  in  practice.  The  briefing  efforts  necessary  to  use  different  simulation 
and  C31  systems  is  tremendous.  This  labour  should  not  be  complicated  by  different  graphical  user 
interfaces  (GUI)  and  other  aspects  of  SW  ergonomics.  Again,  a  kind  of  standard  should  be  designed, 
including  the  arrangement  of  menus,  statistical  information  and  scenario  editors.  Otherwise,  no  single  user 
will  be  able  to  keep  an  overview  and  face  validation  would  be  impossible. 


8.  SUMMARY,  CONCLUSION  AND  A  CRITICAL  REMARK 

The  successful  interoperation  of  model  based  information  systems  is  not  only  a  technical  or  syntactical 
problem.  Most  of  the  real  challenges  occur  on  the  semantic  and  even  more  on  the  pragmatic  level.  The 
only  practicable  way  to  overcome  these  challenges  are  strict  standardisation  or  (and)  time  consuming 
additional  test  and  adjustment  phases  with  the  model  federations.  The  arguments  presented  in  this  paper 
have  been  confirmed  by  examples  from  the  simulation  domain.  However,  the  author  is  convinced  that 
similar  experiences  have  been  made  in  the  traditional  C3I  domain. 

The  main  conclusion  for  the  coupling  of  NATO  simulation  and  C3I  systems  is  that  the  scope  of 
standardisation  should  be  extended  to  pragmatic  issues,  too.  For  that  reason,  it  is  necessary  to  unfold  the 
conceptual  models  of  the  simulation  or  C3I  systems  as  clear  as  possible. 

It  should  be  remembered  that  the  models  developed  in  operations  research  should  always  be  tailored  to 
solve  one  special  problem  or  to  fulfil  one  special  purpose.  Coupling  them  often  implies  to  blur  specific 
adaptations  of  the  models  to  their  original  purpose.  “Monolithic”  should  therefore  not  become  a  negative 
attribute  in  itself. 
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ABSTRACT 

The  1998  Computer  Generated  Forces  (CGF)  Conference  included  a  paper  [1]  which  proposed  a 
Technical  Reference  Model  (TRM)  for  interoperability  between  U.S.  Command ,  Control,  Communication, 
Computers,  Intelligence,  Reconnaissance,  and  Surveillance  systems  (C4ISR)1  and  Computer  Generated 
Force  simulations  (Sim).  This  TRM  characterized  the  “type  of  information  that  is  necessaiy  to  pass 
between  C4ISR  and  CGF  systems’’.  Since  then,  changes  have  occurred  in  technology  for  interfaces;  the 
uses  for  interfaces;  and  the  Architecture(s)  upon  which  they  are  based.  In  addition,  significant  changes 
have  occurred  in  the  respective  source  and  target  systems  that  these  interfaces  connect,  namely  C4ISR 
systems  and  simulations.  Finally,  substantial  interest  has  been  expressed  in  the  availability  of  C4ISR 
hosted  simulation  components,  as  well  as  the  integration  and  exchange  of  components  between  the  two 
domains.  A  recent  Simulation  Interoperability  Standards  Organization  (SISO)  Simulation  Interoperability 
Workshop  (SIW)  paper  [2]  has  proposed  substantial  changes  to  reflect  the  evolution  of  technology >, 
supported  systems,  current  interface  practices,  and  near  term  future  uses  for  C4ISR  -  M&S  interfaces. 

This  paper  briefly  describes  the  revised  version  of  the  TRM.  It  suggests  when  and  how  to  use  the  TRM  in 
reference  to  NATO  Command,  Control,  Communication,  and  Intelligence  (C3I)  system  to  modeling  and 
simulation  (M&S)  interoperability  or  integration  efforts.  It  shows  the  TRM’s  relationship  to  current  NATO 
models  and  standards  in  the  C3I  domain,  as  an  aid  to  those  concerned  with  interoperability,  integration, 
or  standardization  efforts  between  the  two  types  of  systems.  The  paper  explores  the  use  of  the  TRM  in  light 
of  NATO  interoperability  efforts,  and  reflects  on  the  relationship  between  the  C4ISRJSim  TRM  and  NATO 
guidance  documents/standards  such  as  the  NATO  C3  Technical  Architecture  (NC3TA),  the  NATO 
Common  Operating  Environment  (NCOE)  Model  (NCOM),  and  others. 


1.0  INTRODUCTION 

In  1998,  a  TRM  for  interoperability  between  C4I  systems  and  simulations  was  developed  and  proposed  to 
the  1998  Computer  Generated  Forces  Conference  [1],  Since  first  proposed,  the  TRM  has  generated  a 
substantial  amount  of  interest  within  the  US  C4I  -  M&S  interface  community,  particularly  within  the 
Simulation  Interoperability  Standards  Organization  (SISO)  Simulation  Interoperability  Workshop  (SIW) 
conferences.  It  has  been  the  focus  of  several  SIW  study  groups  intended  to  “formulate  a  broad-based 
technical  model  to  describe  and  categorize  interoperability  of  systems  or  classes  of  systems”  [3,4,5].  The 
work  and  discussion  of  these  groups  continues,  as  well  as  their  desire  to  “leverag[e]  existing  work  and 
foster  development  of  that  TRM  into  a  formal  SISO  product.” 


1  C4ISR  systems  are  the  US  DoD  functional  equivalent  to  NATO  Command,  Control,  Communication,  and  Intelligence  (C3I) 
systems 


RTO-MP-MSG-022 


Paper  presented  at  the  MSG-022/SY-003  Conference  on  “C3I  and  M&S  Interoperability  ", 
held  in  Antalya,  Turkey,  9-10  October  2003,  and  published  in  RTO-MP-MSG-022. 


18-1 


C4ISR/Sim  TRM  Applicability  to  NATO  Interoperability 


ORGANIZATION 


Interoperability  Technical  Reference  Model  (TRM) 


c 

4 
I 

5 

y 

s 

t 

e 

m 


Simulation  Service  Interactions 

 Simulation  Metadata 


Execution  Control 


Visualization 


Data  Collection 


Simulation  Effects 


Non-Persistent  Data 

^  Orders 


Reports 


Imagery 


Tracks 


,  Unit  Data  (OB,  TOE,  Symbology,  etc) 


Persistent  Data 

Mission  &  Plan  Information 
Comms  Plan  (Radio/Network  Setup,  etc) 
Weather  Data 
Terrain  Specification 


C4I  System  Service  Interactions 

System  Health/Heartbeat/Status 
Component  Service  Protocols 


Simulation  System 


Simulation  Control  Module 


Visualization  Module 


Simulation  &  Models  Module 


Behavior  Models 

Simulation 

Physical  Models 

Engine 

Communication  Models 


Environmental  Models 


Run-time  Framework 


Figure  1  -  C4I  -  M&S  Interoperability  Technical  Reference  Model 

At  the  Spring  2003  SIW,  the  author  proposed  substantial  changes  to  the  TRM  [2],  as  reflected  in  Figure  1 
(Following  page).  These  changes  are  being  considered  by  the  current  SISO  C4I  -  Simulation  TRM  Study 
Group,  and  are  expected  to  become  part  of  the  formal  C4I  -  Simulation  TRM  (C4I/Sim  TRM).  Section  2 
of  this  paper  provides  an  overview  of  the  proposed  C4I/Sim  TRM,  with  additional  detail  in  the  source 
paper  [2]  and  study  group  sourcebook  [6]. 

The  remainder  of  this  paper  is  organized  as  follows:  Section  2-4  provide  an  overview  of  the  C4ISR/Sim 
TRM,  Section  5  provides  an  introduction  to  various  analysis  sections  which  follow  (Sections  6-9),  Section 
10  summarizes  the  result,  with  specific  recommendations  to  the  NATO  Modelling  and  Simulation  Group 
(NMSG). 

2.0  C4I  -  M&S  INTEROPERABILITY  TRM  OVERVIEW. 

The  C4I/Sim  TRM  is  intended  to  be  a  generalized  model  of  the  components  and  interactions  that  are 
considered  significant  to  efforts  to  establish  interoperability  between  C3I  and  simulation 
systems/components,  regardless  of  application  for  the  interface  effort.  It  is  NOT  intended  to  represent  any 
specific  simulation  system,  or  current/future  interface.  Any  level  of  detail  within  the  C3I  system  has  been 
intentionally  omitted,  as  these  systems  are  generously  described  in  other  documentation,  such  as  the  US 
DOD  TRM  [10,11]  or  NATO  TRM[16  -  20],  The  detail  within  the  simulation  system  is  kept  at  a  high 
level  of  components  that  might  be  candidates  for  distribution  in  an  architectural  design.  Another  purpose 
for  the  high  level  Sim  components  is  to  suggest  those  that  might  be  interchanged  with  C3I  components  as 
found  in  the  NATO  Common  Operating  Environment  (COE)  “basket  of  products”.  Finally,  the  level  can 
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be  used  to  suggest  possible  candidates  for  component  level  integration,  both  using  simulation  components 
on  board  the  C3I  system  and  also  using  C3I  components  to  facilitate  interoperability  during  interface 
efforts.  The  scope  of  the  C4I/Sim  TRM  is  intended  to  allow  for  the  consideration  of  component  level 
interoperability,  as  well  as  systems  level  interoperability  between  simulation(s)  and  C3I  system(s).  The 
C4I/Sim  TRM  is  intended  to  be  appropriate  whether  the  application  for  the  interface  is  training/computer 
aided  exercises  (CAX),  C3I  system  evaluation/test,  acquisition,  or  simulation  based  decision  support  tools 
residing  on  (or  remote  from)  the  C3I  system. 

Changes  in  the  way  that  C3I  systems  have  been  developed,  in  particular  through  the  use  of  a  Common 
Operating  Environment  (COE),  have  made  them  more  modular  or  “component”  based.  Taking  advantage 
of  these  changes,  the  interface  community  has  more  frequently  re-used  core  components  from  C4I  systems 
(e.g.  message  processors,  database  management  systems,  comms  modules)  in  interfaces  to  reduce  costs 
and  improve  interoperability. 

The  goal  of  the  TRM  is  to  assist  programs  in  achieving  more  effective  levels  of  portability  and 
interoperability  in  the  following  ways: 

By  providing  a  consistent  and  common  lexicon  for  description  of  interoperability  requirements  between 
diverse  systems 

•  By  providing  a  means  for  consistent  specification  and  comparison  of  system/service  architecture 

•  By  providing  support  for  commonality  across  systems 

•  By  promoting  the  consistent  use  of  standards 

•  By  aiding  in  the  comprehensive  identification  of  information  exchange  and  interface  requirements 

Although  the  TRM  is  based  on  current  and  past  project  experiences,  it  is  intended  to  be  evolutionary  and 
flexible  enough  to  support  future  needs,  regardless  of  range  of  requirements  or  architecture  configuration. 
Users  are  encouraged  to  use  the  TRM  for  guidance,  and  extract  only  those  elements  that  support  their 
specific  project  needs. 


3.0  TRM  INTERACTION  CATEGORIES 

Connecting  the  separate  systems  (or  components)  are  Interactions,  which  are  collected  together  into  4 
categories.  These  categories  of  information  exchange  include  service-oriented  groupings  for  each 
domain’s  systems  (C4I,  Simulation)  and  the  core  data  that  would  be  of  interest  to  both  systems  (Persistent 
and  Non-Persistent  data)  during  interface  and/or  integration  activities.  In  two  cases  (Simulation  Service 
and  Non-Persistent  Data)  individual  lines  are  detailed  to  represent  individual  classes,  while  in  the  others  a 
single  line  reflects  the  entire  class,  with  examples  of  information  exchanges  provided  for  consideration. 
The  reason  for  the  distinction  between  generalized  categories  and  specific  interactions  is  that  in  the  2 
detailed  categories  cases  sufficient  work  has  been  done  to  identify  the  specific  classes,  and  it  is  expected 
that  these  classes  are  complete.  An  additional  reason  for  the  distinction  is  that  in  the  two  well-defined 
categories,  the  information  exchanged  is  generally  referred  to  in  a  similar  way  within  the  M&S  and  C3I 
communities. 

To  contrast  this  against  the  remaining  two  general  categories  (Persistent  Data,  C4I  System  Service),  the 
lists  presented  are  considered  representative,  and  subject  to  variability  depending  on  the  C3I  system. 
Further,  it  is  felt  that  to  completely  enumerate  all  possible  classes  of  information  within  these  categories 
for  all  possible  C3I  systems  would  be  of  little  use.  Instead,  an  examination  of  requirements  for  each  C3I 
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system  (or  component)  interface  is  needed,  and  consideration  of  the  actual  classes  within  each  category  (as 
well  as  its  relevance  to  the  interface  design)  is  suggested. 

Finally,  the  use  of  bi-directional  arrows  suggests  the  possibility  that  information  flows  within  each  class 
may  go  from  C3I  to  simulation,  or  reverse.  Clearly  the  existence  of  a  particular  class  as  well  as  whether  it 
flows  in  a  single  direction,  or  both  directions,  is  up  to  the  requirements  and  design  of  the  interface.  What 
follows  is  a  general  description  of  the  4  categories.  Additional  information  on  Categories  and  Interaction 
details  can  be  found  in  the  source  paper  [2]  and  C4ISR/Sim  TRM  study  group  sourcebook  [6]. 

3.1  Simulation  Service  Interactions 

To  facilitate  the  distribution  of  simulations,  yet  allow  them  to  be  accessible  to  C3I  systems,  interactions 
such  as  those  defined  within  this  category  are  necessary.  These  include  not  only  information  “about”  the 
simulation  (reflecting  the  potential  that  a  variety  of  simulations  are  available),  but  also  the  ability  to 
control  or  coordinate  its  execution  with  C3I  resident  activities,  the  transmission  of  possible  visualization 
data  (although  not  necessarily  images),  mechanisms  for  data  collection  from  one  to  another,  and  the  net 
results  (or  “simulation  effects”)  of  a  simulation  execution. 

3.2  Non-Persistent  Data 

Non-Persistent  Data  identifies  very  frequent  information  exchange  interactions  (typically  messages, 
reports,  or  data  replication)  that  may  occur  between  C3I  and  simulation  systems  (or  components).  It 
represents  the  major  focal  point  for  interfaces  used  for  training  and  CAX.  In  these  applications  most  effort 
for  interfaces  goes  into  generating  products  from  simulated  entities,  or  evaluating  products  from 
operational  C3I  systems.  In  considering  the  potential  use  of  these  interactions  within  a  simulation 
enhanced  C3I  system,  it  is  possible  that  data  from  operational  sources  may  be  duplicated  in  forms  such  as 
these.  This  would  allow  the  use  of  up-to-date  situation  awareness  data  in  Course  of  Action  Analysis 
(COAA)  or  Mission  Rehearsal  while  additional  data  is  received  by  operational  components.  Subsequently, 
revised  data  might  flow  through  these  classes  to  provide  last  minute  checks  against  plan  for  feasibility. 
During  actual  mission  execution,  these  classes  might  provide  valuable  conduits  through  which  data  used 
for  automated  execution  monitoring  might  occur. 

3.3  Persistent  Data 

This  category  represents  operational  data  stores  native  to  the  C3I  system,  and  having  the  characteristic  of 
infrequent  changes  through  the  course  of  a  simulation  execution.  Its  presence  within  an  interface, 
however,  is  important.  The  ability  to  provide  direct  transfer  of  C3I  data  from  suggested  sources  to 
simulation  equivalents  for  scenario  initialization  purposes  can  provide  substantial  cost  savings,  set-up  time 
reductions,  and  increased  flexibility  for  simulation  use.  Significant  results  from  this  type  of  work  are 
reported  in  papers  such  as  Furness  et  al,  “Realtime  Initialization  of  Planning  and  Analysis  Simulations 
Based  on  C4ISR  System  Data”  [12]. 

3.4  C4I  System  Service  Interactions 

These  are  interactions  that  may  be  mandated  by  use  of  particular  C3I  components,  or  merely  by  virtue  of 
being  connected  to  a  C3I  system.  They  may  not  contain  “data”  that  is  exchanged  between  the  two 
domains,  but  may  be  required  in  order  to  connect  to  the  C3I  system,  sustain  the  connection,  or  to  use  a 
particular  C3I  component.  In  the  absence  of  these  interactions,  the  C3I  system  may  fail,  the  interface  may 
not  be  recognized  as  a  valid  C3I  system  (versus  a  commercial  hardware/software  platform),  or  be  unable 
to  communicate  with  a  particular  component.  These  types  of  interactions  tend  to  be  very  C3I 
system/component  specific,  based  on  particular  component  selections,  hardware/software  architecture 
implementation,  or  C3I  system  version.  Therefore,  no  attempt  is  made  to  enumerate  them  exhaustively. 
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Rather,  two  general  types  are  identified  for  illustrative  purposes. 

4.0  Simulation  System  Components 

The  concept  behind  simulation  component  modules  is  that  they  should  represent  the  smallest  reasonable 
piece  that  might  be  a  candidate  for  distribution  in  an  architectural  design.  In  fact,  they  could  potentially 
represent  individual  “services”  distributed  and  tied  together  with  the  Run  Time  Framework.  Further,  they 
need  not  be  a  single  instance,  but  could  be  multiplied  across  an  implementation  network.  This  would  be 
true  if  used  to  design  client/server  configurations.  This  serves  to  recognize  the  simulation  community’s 
work  on  developing  “federations”  of  simulations.  In  addition,  it  also  extends  the  possibility  to  consider 
that  such  “federations”  may  be  available  to  C3I  systems,  which  might  control  selection  of  federates  used 
to  produce  simulated  results  via  guidance  provided  through  Simulation  Metadata  interactions. 

The  simulation  system  components  represented  in  Figure  1  are  generalizations  that  would  be  considered 
most  useful  for,  or  relevant  to  C3I  to  simulation  interfaces,  or  potentially  useful  for  integration  between 
systems.  It  is  not  intended  that  the  components  identified  here  represents  a  complete  set  required  for  any 
simulation  system.  Further  refinement  of  the  C4ISR/Sim  TRM  may  expand  this  area,  or  ultimately  there 
may  be  an  effort  to  define  and  establish  a  reference  model  for  simulations  or  synthetic  natural 
enviromnents.  To  date,  beyond  the  work  done  on  the  C4ISR/Sim  TRM  described  as  part  of  this  (and 
earlier)  paper  and  the  SISO  study  group,  there  has  been  no  effort  to  put  forth  an  M&S  reference  model, 
although  the  author  believes  there  may  be  some  value  in  doing  so.  There  has  also  been  little  effort  to 
establish  a  common  M&S  implementation  (e.g.  M&S  COE).  It  may  be  possible  that  such  efforts  will  be 
undertaken  in  the  future,  and  as  a  result  (as  described  in  [8])  interoperability  and  reuse  of  simulation 
components  will  be  improved. 

In  the  absence  of  an  accepted  M&S  Technical  Reference  Model,  components  are  included  in  the 
C4ISR/Sim  TRM  for  the  purposes  of  architectural  design  consideration.  Further  efforts  for  C4ISR/Sim 
TRM  refinements  in  the  simulation  system  components  area  include  an  examination  of  its  completeness 
against  the  work  of  the  European  Co-operation  for  the  Long-term  In  Defence  (EUCLID)  project  [21].  A 
comparison  against  the  EUCLID  synthetic  environment  architecture,  as  well  as  components  contained 
within  the  EUCLID  repository  may  confirm  the  accuracy  of  this  area  of  the  TRM,  or  provide  clues  how  it 
could  be  appropriately  refined.  As  an  alternative,  additional  abstractions  for  the  simulation  components 
may  come  from  examination  of  the  component  architectures  of  such  systems  as  OneSAF  [13]. 


5.0  NATO  MODELS  &  STANDARDS  RELEVANCE  INTRODUCTION 

Part  of  the  work  of  the  first  SIW  TRM  Study  Group  [3]  was  to  identify  5  guiding  principles  for  the 
development  of  a  C4ISR/Sim  TRM.  This  work  concluded  that  the  C4ISR/Sim  TRM  must  be: 
Comprehensive,  Traceable,  Easy  to  Interpret,  Usable,  and  Independent.  It  also  presented  a  cursory  look  at 
several  M&S  and  other  reference  models,  although  it  did  not  establish  or  reflect  the  relationship 
(traceability)  between  the  C4ISR/Sim  TRM  and  these  other  reference  models.  This  paper  seeks  to 
establish  the  relevance  of  the  C4ISR/Sim  TRM  to  the  international  NATO  community  by  examining 
several  NATO  reference  models  and  standards,  and  illustrating  their  relationship  to  the  C4ISR/Sim  TRM 
in  greater  detail. 

The  Software  Engineering  Institute  (SEI),  in  their  Software  Technology  Review  [9]  states:  “Much 
confusion  exists  regarding  the  definition,  applicability,  and  scope  of  the  terms  reference  model, 
architecture,  and  implementation.”  They  go  on  to  provide  definitions  for  these  terms  (Table  1)  and 
illustrative  examples  of  the  relationship  between  these  concepts.  In  keeping  with  the  SEI  definition  for 
reference  model,  the  C4ISR/Sim  TRM  is  intended  to  be  a  description  of  all  possible  software  components 
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or  component  services  and  the  relationships  between 
them. 

Although  repeatedly  considered,  no  effort  has  been 
made  to  identify  specific  (or  abstract)  components 
for  the  C3I  system  portion  of  the  diagram.  The 
rationale  for  this  is  that  C3I  systems  are  subject  to 
their  own  reference  models  (e.g.  DoD  TRM,  NATO 
TRM),  architectures  (e.g.  JTA,  NATO  C3  Technical 
Architecture),  and  implementations  (e.g.  DoD  COE, 

NATO  COE).  Underlying  each  of  these  are 
sustainment  efforts  to  continually  evaluate  and 
maintain  reference  and  usage  documentation.  With 
all  of  these  instances,  the  goal  (among  others)  is  to 
establish,  guide,  measure,  or  improve 
interoperability  between  systems  or  components.  As 
with  these  efforts  from  the  C3I  domain,  that  is  a 
primary  goal  of  the  C4ISR/Sim  TRM. 

In  the  following  analysis  sections  the  discussion 
starts  with  showing  the  traceability  from  the 
C4ISR/Sim  TRM  to  the  NATO  TRM  (NTRM). 

As  an  architecture  is  considered  a  subset  description 
of  a  reference  model  for  a  particular  domain,  the 
NATO  C3  Technical  Architecture  (NC3TA)  is 
considered  to  be  relevant  in  the  domain  of  NATO 
C3I  systems.  The  NC3TA  provides  the  principal 
source  of  procedures,  architectural  concepts,  data 
(standards  and  products),  and  their  relationships, 
from  which  the  Technical  View  of  C3I  systems  or 
“system  of  systems”  can  be  developed.  From  such  a 
defined  architecture  individual  C3I  systems  are 
composed. 

This  paper  seeks  to  argue  the  relevance  and  validity  of  the  C4ISR/Sim  TRM  to  the  NATO  community, 
and  its  potential  relationship  to  the  NC3TA.  To  do  so,  an  examination  of  the  traceability  of  the  C4ISR/Sim 
TRM  to  various  portions  of  the  NC3TA  is  considered.  In  particular,  Section  7  looks  at  the  NATO  COE 
(NCOE)  and  NCOE  Component  Model  (NCM).  Section  8  proposes  a  simulation  server  functional 
configuration,  and  Section  9  relates  the  C4ISR/Sim  TRM  to  the  NC3TA  Interoperability  Model. 


Reference  Model:  A  reference  model  is  a 
description  of  all  of  the  possible  software 
components  or  component  services  (functions), 
and  the  relationships  between  them  (how  these 
components  are  put  together  and  how  they  will 
interact). 

Architecture:  An  architecture  is  a  description  of 
a  subset  of  the  reference  model’s  component 
services  that  have  been  selected  to  meet  a 
specific  system’s  requirements.  In  other  words, 
not  all  of  the  reference  model’s  component 
services  need  to  be  included  in  a  specific 
architecture.  There  can  be  many  architectures 
derived  from  the  same  reference  model.  The 
associated  standards  and  guidelines  for  each 
service  included  in  the  architecture  form  the 
open  systems  architecture  and  become  the 
criteria  for  implementing  the  system. 

Implementation:  The  implementation  is  a 
product  that  results  from  selecting,  reusing, 
building,  and  integrating  software  components 
and  component  services  according  to  the 
specified  architecture.  The  selected,  reused, 
and/or  built  components  and  component 
services  must  comply  1 00%  with  the  associated 
standards  and  guidelines  for  the  implementation 
to  be  considered  compliant. 


Table  1  -  SEI  Definitions 


6.0  NATO  TECHNICAL  REFERENCE  MODEL  (NTRM) 

The  NTRM  [17]  provides  guidance  to  NATO  developers,  system  architects,  and  individuals  in  using  and 
developing  systems  and  technical  architectures.  The  model  promotes  open  system  design,  as  well  as  the 
decoupling  of  application  and  external  environment  from  the  operating  platform.  It  is  based  on  national 
defense  (US  DoD  TRM),  aerospace  (NASA  Space  Generic  Open  Avionics  Architecture  Model),  and 
automotive  (SAE  GOA  model)  industry  efforts.  The  NTRM  contains  basic  elements  of  the  POSIX  OSE 
Reference  model,  which  includes  three  classes  of  entities  (Application  Software,  Application  Platform, 
External  Environment)  and  two  types  of  interfaces  (Application  Program,  External  Environment).  The 
main  purpose  of  the  NATO  TRM  (NTRM)  is  to  structure  the  standards  listed  in  the  NATO  Common 
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Standards  Profile  (NCSP)  [19]. 

Within  the  NTRM,  there  are  12 
service  areas  defined,  which  are 
later  used  organize  standards  within 
the  NCSP.  In  addition,  there  are  7 
application  types  (Mission  Area 
Applications  and  6  Support  types). 

In  order  to  assess  the  relationship 
between  the  NTRM  and  C4ISR/Sim 
TRM,  an  attempt  was  made  to  map 
the  simulation  modules  into  the 
various  services  and  applications 
described  in  the  DoD  TRM.  The 
results  are  presented  in  Figure  2  and 
discussion  of  the  results  follows. 

In  general,  each  module  was  able  to 
map  to  several  NTRM  services 
and/or  applications.  This  reflects  the 
fact  that  as  a  reference  model,  it 
represents  a  potentially  unlimited 
number  of  architectural  definitions 
and/or  implementations.  In  several 
cases,  the  modules  were 
successfully  mapped  to  items  in  both 
the  service  and  application 
categories.  This  would  credit  the  fact  that  simulations,  due  to  their  power  and  flexibility,  can  be  seen  to 
provide  both  application  capabilities  to  the  end-user,  as  well  as  perform  service  level  functions  to  the 
system  and/or  other  applications. 

For  the  C4ISR/Sim  TRM  Simulation  Control  module,  the  limited  descriptions  provided  for  NTRM  service 
areas  suggest  that  a  relationship  would  exist  between  Simulation  Control  module  and  NTRM  User 
Interface  Services,  or  NTRM  System  Management  Services,  or  both.  Clearly,  the  simulation  control 
module  might  represent  the  user  interface  to  the  simulation  “service”  and  provide  management  capabilities 
for  it.  But  depending  upon  the  specific  architecture,  it  may  (or  may  not)  provide  a  user  interface,  style 
sheets,  direct  access  to  simulation  capabilities,  etc.  If  the  user  interface  services  class  was  intended  to 
represent  only  those  on-board  capabilities  to  construct  and  control  user  interfaces  (e.g.  browser, 
Xwindows)  then  the  simulation  control  module  would  be  squarely  within  the  system  management  services 
area. 

Similarly,  the  Visualization  module  could  map  to  one  of  two  different  NTRM  service  areas,  either  User 
Interface  services  or  Graphics  services.  In  this  case,  the  visualization  may  represent  intermediate  results  of 
simulation  activities.  Often  this  would  be  displayed  on  some  form  of  two  dimensional  planned  view 
display  (PVD)  or  possibly  overlaid  onto  a  map.  The  potential  mapping  to  User  Interface  Services  might 
assume  the  development  and  acceptance  of  a  simulation  domain  standard  PVD  or  Graphic  Information 
System  (GIS)  as  a  User  Interface  Service.  In  contrast  to  a  similar  evaluation  of  the  C4ISR/Sim  TRM 
against  the  US  DoD  TRM  [15],  the  Visualization  module  was  mapped  easily  to  the  Multimedia  Services 
category  not  present  in  the  NTRM.  In  the  US  DoD  TRM,  the  Multimedia  Services  category  contains  a 
descriptive  reference  to  GIS  services,  while  the  Graphics  Services  (within  NTRM)  simply  refers  to 
“functions  required  for  creating  and  manipulating  pictures.” 


C4ISR/M&S  TRM 
Module 

NATO  TRM  relevant  Application  and 
System  Service  Areas 

Simulation  Control 

User  Interface  Services 

System  Management  Services 

Visualization 

User  Interface  Services 

Graphics  Services 

Simulation  &  Models 
Module 

Mission  Area  Application 

Engineering  Support  Applications 

Common  C2  Applications  Services 

Simulation  Engine 

Mission  Area  Application 

Engineering  Support  Applications 

Common  C2  Applications  Services 

Models 

Mission  Area  Application 

Engineering  Support  Applications 

Common  C2  Applications  Services 

Run-Time  Framework 

Distributed  Computing  Services 

Data  Interchange  Services 

Databases 

Database  Utilities  Applications 

Data  Management  Services 

Figure  2  -  C4ISR/Sim  Mapping  to  NTRM 
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The  simulation  and  models  aggregate  component  might  be  instantiated  as  a  Common  C2  Application,  or  a 
stand-alone  Mission  Area  Application.  Further,  it  is  also  identified  as  a  potential  Engineering  Support 
application.  Unfortunately,  there  is  an  absence  of  descriptions  for  applications  (including  Engineering 
Support)  within  NTRM  documents  available,  however  the  US  DoD  TRM  Engineering  support  description 
refers  to  “decision  support  services”,  “modeling  and  simulation  services”,  and  “expert  system  services”, 
all  of  which  are  potential  applications  for  modeling  and  simulation  interfaces  or  integration. 

Although  simulation  engine(s)  or  model(s)  are  highly  unlikely  to  be  embedded  (or  interfaced  to)  by 
themselves,  the  possibility  exists.  As  an  example,  it  might  be  desirable  to  embed  a  simulation  engine, 
which  dynamically  loads  models  (as  data  parameters,  executable  components,  etc)  from  some  central 
repository.  Therefore,  these  would  have  the  same  potential  mapping  as  the  simulation  and  models 
aggregate  component.  Other  then  this  possibility,  more  obscure  mappings  could  be  made  (e.g.  Simulation 
Engine  -  Mission  Area  Application  /  Models  -  Data  Management  Services). 

Finally,  both  Run-Time  Framework  and  Databases  could  map  into  two  categories,  depending  principally 
on  the  intended  implementation  architecture.  In  the  case  of  the  Run-Time  Framework,  perhaps  the  more 
acceptable  mapping  would  be  into  Distributed  Computing  Services.  This  is  due  to  the  fact  that  the 
Distributed  Interactive  Simulation  (DIS)  protocol  is  already  an  accepted  standard  within  the  NCSP  for 
simulation  use. 

It  was  consideration  of  the  module  mappings  that  reinforced  that  the  NTRM  is  a  very  generalized  model 
and  as  such  cannot  (or  has  not  yet)  identified  all  possible  domain  services  that  could  be  provided.  Also, 
there  is  presently  limited  documentation  to  describe  various  entities,  applications,  and  service  areas,  which 
makes  a  specific  direct  mapping  difficult.  However,  in  several  cases  (specifically  Run-Time  Framework 
and  Databases)  descriptions  provided  within  NTRM  documents  provides  a  somewhat  clearer  definition  as 
to  the  potential  implementation  method  or  purpose  for  the  modules.  Therefore,  although  there  is  value  in 
considering  a  mapping  to  NTRM  areas  for  the  purposes  of  communication  with  systems  designed  and 
built  using  this  model,  there  is  still  relevance  to  a  domain  specific  model  such  as  the  C4I/Sim  TRM,  which 
contains  descriptions  that  should  be  more  clear  to  simulation  domain  practitioners.  However,  the  most 
ideal  solution  might  be  the  use  of  both  reference  models  for  a  more  complete  description  of  architectural 
components,  modules,  and  implementation  possibilities. 


7.0  NATO  COMMON  OPERATING  ENVIRONMENT  (NCOE) 

The  goal  of  the  NCOE  is  to  support  the  development  of  a  distributed  information  system  infrastructure, 
which  promotes  interoperability.  The  NCOE  provides  the  minimum  set  of  services,  common  standards 
profiles,  management  procedures,  implementation  rules,  interfaces,  and  guidelines  for  product  selection, 
as  well  as  products  to  implement  NATO  Information  Systems  (NIS).  The  objective  is  to  ensure  their 
interoperability  within  NATO  and  with  national  systems. 

The  NCOE  Component  Model  (NCM)  [20]  capitalizes  on  the  NATO  Technical  Reference  Model 
(NTRM),  utilizing  its  top-down  layered  architecture.  Individual  components  can  be  described  as  the 
individual  capabilities  that  are  transparent  to  the  end-user.  Components  are  in  essence  the  distributed 
computing  capabilities,  data  interchange  services,  management  services,  communications  services,  data 
management  services,  presentation  services,  security  services,  etc.  that  are  inherent  to  the  NCOE  as 
depicted  in  the  NCM  in  accordance  with  the  NTRM.  The  NCM  depicts  the  high-level  functional 
taxonomy  and  overall  composition  of  the  NCOE.  Within  the  NCM,  each  individual  component  is 
categorized  according  to  the  type  of  service  provided.  However,  the  NCM  only  provides  a  view  of 
individual  component  relationships  by  service  area  only.  The  actual  products  necessary  to  populate  each 
service  area  are  selected  from  the  NCOE  'basket  of  products'. 
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Figure  3  -  C4ISR/Sim  TRM  to  NCM  Mapping 


An  analysis  was  done  to  reflect  the  mapping  between  the  C4ISR/Sim  TRM  and  the  NCM.  The  results  are 
provided  in  Figure  3.  However,  as  described  in  the  details  below,  a  number  of  simulation  specific  services 
(or  components  within  the  C4ISR/Sim  TRM)  remain  difficult  to  classify. 

Visualization  would  seem  to  be  implementation  dependent,  but  could  be  subject  to  some  confusion  based 
on  the  underlying  technology  chosen  for  implementation.  For  example,  simulation  displays  that  were 
based  on  GIS  packages  would  clearly  be  able  to  fit  within  the  Geospatial  Services  category.  However  this 
category  seems  to  be  identifying  those  components  that  are  end  point  GIS  systems,  rather  then  simulation 
adaptation  of  these  products  that  provide  “added  value”  (e.g.  displaying  simulation  progress  on  map 
products).  Further,  several  existing  simulations  considered  during  the  development  of  the  C4ISR/Sim 
TRM  utilize  “home  grown”  PVDs,  based  on  X  Window,  OpenGL,  or  VRML  technologies  (for  example). 
These  technologies/components  are  suggested  within  the  presentation/multimedia  services  area,  and 
therefore  it  may  be  appropriate  for  these  Visualization  components  to  reside  there.  Yet  instances  exist 
where  simulation  visualization  tools  may  be  distributed  independent  of  the  simulation  portion  itself,  so 
correct  placement  within  the  NCOE  may  be  important. 

Similarly,  Models  do  not  easily  fit  into  a  single  component  category,  because  of  the  “value  added”  that 
they  provide.  Potentially  instantiated  as  a  model  repository,  they  may  consist  of  data  files  or  objects,  with 
their  own  repository  infrastructure.  However,  this  does  not  necessarily  qualify  them  for  data  management, 
or  distributed  object  services  if  these  categories  refer  to  domain  independent  tools.  Clearly  at  some  level 
they  represent  “data”  or  “objects”,  but  specific  to  the  M&S  domain  and  in  conjunction  with  (or  without) 
the  Simulation  Engine  they  represent  a  potentially  powerful  “service”  that  can  be  invoked  by  other 
applications,  or  as  mission  applications  themselves. 

The  Simulation  &  Models  module  and  Simulation  Engine  component  doesn’t  fit  easily  within  Common 
Support  Services  or  Infrastructure  Services  Categories.  As  a  default,  they  were  associated  with  the 
Common  C2  Application  service,  although  they  did  not  seem  to  be  consistent  with  the  service  description 
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Figure  4  -  Proposed  Functional  Components  for  Simulation  Server 

provided.  Simulations,  models,  and  simulation  engine  products  exist  in  a  variety  of  forms,  not  only  from 
commercial  vendors  but  also  as  by-products  of  nationally  sponsored  simulation  efforts.  As  stated  in  [20] 
“The  primary  intent  of  the  Common  Support  Applications  is  to  provide  the  architectural  framework 
necessary  for  the  management,  distribution  and  sharing  of  information  among  applications  throughout  a 
system.”  Further,  “Infrastructure  services  provide  a  set  of  integrated  capabilities  that  the  applications  will 
access  to  evoke  NCOE  services,  and  are  necessary  to  move  data  through  the  network.”  Based  on  the 
examination  of  these  definitions  and  other  documentation  of  existing  services  categories,  it  was  considered 
that  a  clear  direct  mapping  of  these  simulation  components  was  difficult. 

As  a  result,  it  may  be  of  value  for  the  NMSG  to  consider  development  and  proposal  of  an  additional 
Common  Support  Service  category.  This  category  might  be  specifically  oriented  toward  simulation-based 
applications  or  more  generalized  decision  support  services.  These  might  not  be  mission  applications 
themselves,  but  could  provide  powerful  simulation  based  information  processing  or  analysis  capabilities  to 
a  wide  audience  of  Mission  Application  developers.  They  could  also  represent  the  domain  specific 
versions  of  various  other  services/applications  (e.g.  visualization,  model  repositories)  that  could  be  shared 
among  simulation  developers,  or  instantiated  onto  C3I  systems. 

As  an  example  category,  “Decision  Support  Services”  might  apply  to  a  category  of  service  level 
applications  that  provide  intermediate  processing  of  data/information  from  lower  level  (Infrastructure 
Service)  components  or  data  sources.  Yet  these  “Decision  Support  Service”  components  may  be  general 
enough  that  they  can  be  reused  based  on  a  common  input  format/standard  and  appropriate  APIs.  To  extend 
the  recommendation,  it  could  be  considered  a  “base”  component,  similar  to  “Document  Management”, 
“Message  Handling”,  “Office  Automation”,  or  “Geospatial  Services”. 


8.0  REFERENCE  MODELS  FOR  FUNCTIONAL  CONFIGURATIONS 

Volume  2  of  the  NC3TA  [17]  introduces  Functional  Configurations  (FC),  which  are  composed  of 
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application  and  foundation  services  and  interface  functionally  with  one  another.  A  full  overview  of  FCs  is 
provided  in  Annex  B,  and  shows  9  FC  examples  that  constitute  an  initial,  although  not  all-inclusive  list  of 
FCs  that  will  be  validated  and/or  updated  in  future  versions  of  the  NC3TA.  An  examination  of  the  existing 
FCs  resulted  in  none  that  appeared  fully  appropriate  for  a  simulation  server  configuration.  As  a  further 
evaluation  of  the  utility  of  the  C4ISR/Sim  TRM,  a  proposed  FC  configuration  was  developed  and  appears 
as  Figure  4. 

The  motivation  of  a  simulation  server  FC  is  the  same  as  other  FCs.  It  can  be  used  to  reduce  architectural 
complexity,  promote  and  encourage  the  judicious  use  of  NCOE  components,  and  improve  interoperability. 
These  and  other  reasons  are  consistent  with  recommendations  made  to  SISO  for  the  establishment  of  an 
M&S  COE  in  a  recent  paper  entitled:  “Interoperability  and  Reuse  through  a  Modeling  and  Simulation 
Common  Operating  Environment”  [14].  Further  motivation  can  be  seen  through  the  existence  of  other 
“server  system”  FCs,  including  Database  Server,  Web  Portal/Application  Server,  Documentation 
Management  Server,  Messaging  and  Communications  Server. 


9.0  NC3TA  INTEROPERABILITY  MODELS 

In  order  to  classify  NC3I  Interoperability,  the  ISC  has  included  in  their  NATO  Policy  for  C3 
Interoperability  (P0(2000)39),  4  degrees  of  interoperability.  These  degrees  are  broken  down  into  sub¬ 
degrees  and  are  intended  to  classify  how  structuring  and  interpretation  of  data  can  enhance  operational 
effectiveness.  The  sub-degrees  are  then  be  mapped  to  groups  of  standards  to  be  referred  to  during  the 
selection  process. 

To  show  the  relationship  between  the  C4ISR/Sim  TRM  and  the  applicable  standards  within  the  NC3TA,  a 
mapping  was  done  from  the  various  interaction  classes  within  the  model  to  the  interoperability  sub¬ 
degrees  within  the  NC3TA.  This  mapping  is  represented  below,  with  specific  point  discussions  to  follow. 
The  utility  of  such  a  mapping  is  that  it  provides  a  guide  to  interface  efforts  as  to  which  categories  of 
standards  need  to  be  considered  during  their  efforts.  It  can  also  serve  as  a  roadmap  for  NMSG  standards 
consideration/development  effort  to  focus  on  those  categories  where  relevant  standards  are  missing. 
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Figure  5  -  C4ISR/Sim  TRM  Mapping  to  NATO  Interoperability  Degrees 


The  Non-Persistent  data  interactions  mapped  easily  to  the  categories  that  would  be  expected  for 
components  and/or  interactions  among  C3I  systems.  In  cases  where  mappings  indicated  above  were 
incorrect,  users  of  the  C4ISR/Sim  TRM  would  be  expected  to  utilize  the  interoperability  profile  for  the 
specific  machine  (or  type  of  machine)  that  was  subject  to  interface  or  integration. 

As  indicated  in  the  C4ISR/Sim  TRM  source  paper  [2],  the  items  within  the  Persistent  Data  and  C4ISR 
System  Service  categories  are  considered  representative  and  subject  to  variability  depending  on  the  C4I 
system  or  proponent  service.  Therefore,  the  mappings  in  these  two  categories  are  also  generally  suggestive 
rather  then  attempting  to  make  a  single  correspondence.  In  these  two  cases,  no  specific  details  for 
interactions  are  made,  but  general  selections  for  sub-degrees  represent  common  categories  for  items 
contained  within  the  Notes  column. 

Identifying  and  categorizing  the  various  simulation  service  interactions  into  sub-degrees  was  somewhat 
easier,  yet  subject  to  the  same  level  of  variability.  The  most  likely  form  for  simulation  meta-data  would 
seem  to  hypertext  or  XML  formatted  messages.  For  the  purposes  of  simulation  execution  control,  the 
example  of  legacy  system  usage  of  specific  protocols,  such  as  Distributed  Interactive  Protocol  (DIS), 
Aggregate  Level  Simulation  Protocol  (ALSP),  as  well  as  current  use  of  the  High  Level  Architecture 
(HLA)  Run  Time  Infrastructure  (RTI)  were  considered.  Of  these,  only  DIS  is  referred  to  in  the  NC3TA 
standards  document  [18],  although  NATO  acceptance  of  the  HLA  has  occurred. 
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Data  collection  can  take  the  form  of  discovery  (and  transfer)  of  numerous  items  from  the  C4ISR  system, 
and  potentially  from  the  simulation.  As  a  result,  the  sub-degrees  that  would  be  applicable  would  be  as 
wide  as  the  set  of  items  for  each  system  individually.  Research  in  the  area  of  simulation  effects  is  still 
relatively  new,  and  therefore  difficult  to  classify  the  form  that  it  might  take.  It  could  be  a  representation  of 
a  hypertext  document  (2.B),  or  perhaps  a  rendering  on  a  Graphical/GIS  image  (2.D).  Ultimately  it  may 
represent  the  influence  of  a  particular  datafile  or  operational  database  that  is  returned  to  the  C3I  system. 


10.0  SUMMARY 

This  paper  has  provided  an  overview  of  the  evolving  C4ISR/Sim  TRM,  and  examined  the  traceability  of  it 
to  the  various  component  reference  models  and  standards  of  the  NC3TA.  The  importance  of  the 
traceability  to  aid  on-going  efforts  to  establish  C3I  to  simulation  interfaces,  the  use  of  COE  components 
within  those  interfaces,  and  the  desire  to  migrate  simulation  based  components  and  applications  onto  C3I 
systems.  In  the  absence  of  an  accepted  (or  mandated)  simulation  TRM,  the  simulation  community  has 
been  free  to  model,  architect,  and  implement  what  they  choose.  However,  if  those  components  are  placed 
directly  onto  a  C3I  system,  they  would  be  subject  to  the  models,  architecture,  COE,  and  standards  as 
defined  within  the  NC3TA. 

As  the  analysis  has  shown  in  many  cases,  obvious  relationships  exist  between  components  (and 
interactions)  of  the  C4ISR/Sim  TRM  (and  by  extension  the  simulation  domain)  and  the  NC3TA.  In  other 
cases,  the  relationship  is  more  obscure,  principally  due  to  the  “generic”  nature  of  the  NC3TA.  However,  it 
has  been  pointed  out  where  simulation  domain  specific  contributions  can  be  made  within  the  framework  of 
the  NC3TA,  that  would  help  to  make  it  more  relevant  to  the  simulation  community.  Through  efforts  such 
as  this,  it  is  suggested  that  the  task  to  establish  interfaces,  and  integrate  components  would  be  made  easier, 
and  the  results  more  interoperable. 

The  following  are  the  summary  of  the  specific  recommendations  to  the  NMSG  for  this  effort: 

•  Development  and  recommendation  of  simulation  based  Common  Support  Service  category,  for 
inclusion  within  the  NCM. 

•  Development  and  formalization  of  Simulation  based  Functional  Configurations,  Technical 
Configurations,  and  Internal  Interoperability  Profiles. 

•  Identification  of  additional  simulation  based  standards  (e.g.  HLA,  SEDRIS)  for  inclusion  in 
NCSP. 

•  Examination  of  C4ISR/Sim  TRM  to  ensure  that  lexicon  and  representations  are  sufficiently 
generalized  and  consistent  with  NATO  standards. 

•  Further  examination  of  validity  of  C4ISR/Sim  TRM,  and  consideration  of  Annexed  inclusion 
within  the  NC3TA. 
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ALLIED  COMMAND  TRANSFORMATION  ROLE  IN 
MODELLING  AND  SIMULATION 

Commodore  Jon  WELCH 

UKN  DACOS  FC&RT  HQ  SACT 
7857  Blandy  Road 
Norfolk,  VA  23551 
USA 

1 .  The  purpose  of  this  presentation  is  to  give  you  an  update  on  the  Transformation  process 
that  has  taken  place  within  NATO  and  in  particular,  the  Supreme  Allied  Commander 
Transformation  (SACT)  HQ.  How  we  at  SACT  see  ourselves  interfacing  with  R&T  organizations 
and  agencies  and  more  specifically,  how  modeling  and  simulation  will  play  an  important  role  in 
this  process. 

2.  To  effect  a  cohesive,  collaborative  and  focused  transformation,  our  leaders  decided  at  the 
Prague  Summit  in  November  2002  designated  a  command  to  be  the  driver  for  change  within 
NATO.  To  function  as  the  focal  point  for  managing  the  range  of  issues  affected  by 
transformation:  interoperability,  jointness,  experimentation,  education,  and  conceptual  and 
doctrinal  development.  In  order  to  ensure  that  we  find  new  ways  to  sustain  and  improve  our 
ability  to  fight  as  an  interoperable  allied  team,  Allied  Command  Transformation  was  established 
with  responsibility  for  managing  differences  in  capabilities  as  our  militaries  innovate  and 
technology  provides  them  new  tools. 

3.  Allied  Command  Transformation  has  been  assigned  the  mission  of  leading  the 
transformation  of  NATO  forces.  It  will  be  accountable  for  producing  forces  that  bridge  the 
difference  in  alliance  capabilities  and  capitalize  on  the  competitive  advantages  of  national 
contributions.  Supreme  Allied  Commander  Atlantic  transitioned  to  become  the  Transformation 
Strategic  Commander  for  NATO  on  June  19  2003.  SACEUR  became  the  sole  Operational 
Strategic  Command  through  a  realignment  of  functions/  tasks  along  an  operational/functional 
line.  The  NATO  Transformation  process  is  now  established  allowing  one  command  to  be  the 
driver  for  change,  to  provide  the  focused  effort  necessary  to  advance  new  technology,  policy  and 
doctrine  within  the  Alliance.  This  one  command  will  have  the  ability  to  concentrate  on 
Transformation  with  the  other  strategic  commander  focusing  on  operations.  Allied  Command 
Transformation  will  be  the  advocate  for  new  doctrine,  concepts,  and  innovations  within  the 
Alliance. 

4.  To  bring  about  the  Realignment  of  the  two  strategic  commanders  to  realize  on 
operational  and  one  transformational  command,  the  staffs  of  the  two  strategic  command 
headquarters  sat  down  to  assess  the  tasks  assigned  to  each.  The  staffs  identified  operational  tasks 
to  be  transferred  to  SACEUR  as  the  operational  commander  and  tasks  to  be  transferred  to 
SACLANT  in  order  to  identify  all  tasks  and  insure  there  would  be  no  decrease  in  the  output  of  the 
two  strategic  commands  as  they  transitioned  to  their  new  missions. 

It  is  with  this  realignment  of  tasks  and  we  realize  the  mission  and  structure  of  the  two  new 
strategic  commands.  Here  at  HQ  SACT  we  commenced  operating  as  the  transformational 
command  on  1 9  June  2003  with  the  transfer  of  command  authority  of  all  operational  assets  to 
SACEUR,  the  deactivation  of  SACLANT  and  the  activation  of  the  Supreme  Allied  Commander 
Transformation.  Over  the  course  of  the  next  several  months  the  staffs  will  commence  transfer  of 
tasks,  pending  placement  of  budget  and  manpower  at  the  applicable  strategic  command. 
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5.  On  19  June  2003  with  the  activation  of  the  Supreme  Allied  Commander  Transformation, 
we  were  once  again  linked  the  US  Joint  Forces  Command  when  their  commander  was  once  again 
dual  hatted  as  the  Strategic  Commander  for  NATO  here  in  Norfolk.  The  post  for  our  commander 
is  no  longer  gapped  or  filled  in  an  interim  capacity  by  the  Deputy,  but  reflects  the  dual  hatting 
with  US  Joint  Forces  Command.  Our  previous  area  of  responsibility  was  the  North  Atlantic  and 
we  specialized  in  Maritime  issues.  As  a  result  we  have  been  manned  by  Navy  Flag  Officers.  In 
an  effort  to  become  the  Transformation  command  for  NATO  we  are  working  with  nations  to  fill 
posts  with  officers  of  other  services.  As  you  can  see  here  we  are  making  great  strides.  Our  Joint 
Education  and  Training  and  C41  sub-divisions  are  being  headed  by  Air  Force  General  Officers, 
and  we  have  Army  General  officers  holding  the  positions  at  the  Joint  Warfare  Center  /  Strategic, 
Concepts,  Policy  and  Integration  /  and  Defense  Planning. 

6.  We  have  organized  ourselves  into  two  major  departments  -  Transformation  and 
Transformation  Support  under  which  our  divisions  and  sub-divisions  are  aligned.  We  are  a 
totally  new  command  -  in  mission  and  in  structure  and  there  is  no  basis  under  which  the  two  can 
be  compared.  When  our  Outline  Peacetime  Establishment  for  the  headquarters  is  agreed  by 
nations  we  will  have  approx  550  personnel  here  on  staff  at  the  Headquarters.  Given  the  physical 
distance  between  HQ  SACT  and  NATO  HQ  in  Brussels,  the  position  of  the  SACT  Representative 
in  Europe,  or  SACTREPEUR,  cannot  be  understated.  He  and  his  staff  are  physically  located  at 
NATO  Headquarters  and  are  a  vital  link  in  providing  SACT’s  advice  and  perspectives  to  the 
political  and  military  leadership  of  the  Alliance  on  a  daily  basis. 

7.  The  Sub-divisions  are  Implementation  and  Capabilities.  We’ll  first  look  at  the 
Capabilities  functions  to  give  you  a  better  understanding  exactly  what  the  term  capabilities  means 
and  what  some  of  our  outputs  will  be.  Liaison  will  be  established  with  the  US  Joint  Forces 
Command  in  Norfolk,  Virginia  for  transformational  efforts  and  strong  ties  will  be  established 
with  the  staff  at  the  Allied  Command  Operations.  To  fully  execute  our  tasks  of  providing 
education  and  training  for  allied  personnel  we  will  establish  close  working  ties  with  established 
NATO  schools  and  for  experimentation  purposes  we  will  work  closely  with  NC3A,  NURC,  the 
RTO,  and  national  Centres  of  Excellence. 

8.  We  have  made  a  lot  of  progress  in  a  very  short  space  of  time,  but  there  is  a  lot  more  to  do 
yet  before  we  consider  ourselves  fully  transformed.  This  Status/timeline  -  presented  in  the 
Implementation  Directive  provided  by  the  International  Military  Staff  -  is  ambitious  we  know,  but 
it  is  the  goal  that  we  are  working  hard  to  achieve. 

9.  We  think  we  are  still  ahead  of  the  work  -  but  this  represents  a  very  significant  amount  of 


work  still  to  be  accomplished  in  the  near  future. 
Deliver  the  Bi-SC  DIP 

30  Sep  03 

Obtain  MC  agreement  on  Flags  to  Post 

15  Mar  04 

Final  PE  -  MC  agreement 

30  Sep  04 

Begin  manning  of  new  PE  posts  by  Nations  from 

1  Nov  04 

Declare  NCS  IOC  by 

30  Jun  05 

Declare  NCS  FOC  by 

30  Jun  06 

10.  Transformation  in  the  context  of  the  Alliance  is  defined  as  a  continuous  process  of 
development  and  integration  of  innovative  concepts,  doctrine  and  equipment  in  order  to  improve 
the  effectiveness  and  interoperability  of  war- fighting  forces.  During  this  process  the  use  of 
modeling  and  simulation  provides  us  the  capability  to  build  and  test  our  vision,  concepts,  doctrine 
and  equipment  this  way  we  can  create  an  environment  in  which  the  Alliance  is  pro-active  rather 
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than  reactive,  and  where  capability  requirements  are  anticipated  rather  than  developed  following 
emergence  of  new  security  threats.  This  continuous  process  starts  by  identifying  future 
requirements  for  NATO  forces  and  comparing  them  with  current  force  capabilities  and  near  term 
improvements  to  establish  the  extent  of  any  shortfalls.  Potential  solutions  will  be  identified  in  the 
form  of  concepts  that  can  be  developed  and  experimented  within  a  collaborative  manner  with 
Modelling  and  Simulation.  This  concept  work  could  involve  the  development  of  prototype 
equipment,  and/or  doctrine,  training,  infrastructure  improvement.  To  support  this,  Strategic  level 
operational  analyses  will  be  conducted  to  identify  the  type  and  scale  of  capabilities  and 
interoperability  that  the  Alliance  will  require.  In  parallel,  ACT  will  acquire  an  in  depth 
knowledge  of  both  the  Alliance's  current  capabilities  and  intended  improvements  to  national 
capabilities  in  order  to  clearly  establish  where  the  Alliance  needs  to  concentrate  its  future  efforts. 
These  will  inform  the  Defence  Planning  Process  and  will  result  in  a  Strategic  Transformation 
Vision  that  clearly  identifies  and  prioritizes  the  Long  Term  Capability  Requirements  of  the 
Alliance.  As  you  can  see  modelling  and  simulation  will  be  used  every  step  of  the  transformation 
process. 

1 1 .  The  following  activities  of  the  transformation  process  should  be  supported  with 
modelling  and  simulation  tools: 

Analysis  of  Capability  Requirements 
Concept  Exploration  and  Development 
Concept  Experimentation 
Operational  Training  and  Exercises 

12.  Starting  first  with  the  analysis  that  is  conducted  to  identify  NATO’s  capability 
requirements.  This  work  involves  the  assessment  of  NATO’s  capabilities  in  representative 
scenarios  such  that  gaps  in  this  capability  can  be  identified.  To  do  this  work  we  need  models  that 
address  the  new  situations  that  could  confront  us  and  methods  for  comparing  various  response 
options  that  NATO  might  take.  These  situations  involve  traditional  combat,  but  also  peace 
keeping,  information  operations  and  the  military  contribution  to  managing  the  consequences  of 
terrorist  attacks.  Models  should  reflect  the  fact  that  we  are  becoming  more  joint  and  interoperable 
with  various  military  and  civil  bodies  in  various  NATO  and  non-NATO  nations.  Having 
identified  capability  areas  that  require  attention,  we  need  to  develop  concepts  that  address  these 
capability  gaps.  In  this  case,  M&S  support  is  needed  to  evaluate  these  concepts,  including  the 
ability  to  measure  the  impact  of  the  emerging  technologies.  One  area  that  is  particularly 
important  is  the  application  of  M&S  tools  for  the  analysis  of  decision-making  processes  in 
multinational  joint  operations.  Finally,  we  are  recognising  that  some  parts  of  the  military 
capability  spectrum  are  harder  to  simulate  than  others.  For  example,  we  have  extensive  M&S 
capability  in  support  of  logistics  concepts  but  very  little  when  it  comes  to  information  operations. 
Modelling  and  simulation  has  also  an  important  role  in  the  experimentation  process.  The 
simulation  models  allow  examination  of  the  real-world  concepts  in  a  simulated  environment.  The 
live  domain  is  a  representation  of  military  operations  using  live  forces.  The  virtual  domain  is  a 
replication  of  actual  war  fighting  equipment,  systems  and  includes  computer-generated 
battlefields  in  simulators.  The  constructive  domain  includes  simulations  that  represent  actions  of 
people  and  systems  in  the  simulation.  Experiments  could  benefit  from  one  or  combination  of 
these  M&S  domains.  It  is  clear  that  training  and  exercises  will  play  a  major  role  in  future  efforts 
to  transform  NATO  capabilities.  In  this  context,  we  need  a  complementary  set  of  M&S  tools. 
These  tools  should  include  an  advanced  distributed  learning  capability  to  train  the  augmentees 
before  the  exercise  such  that  they  are  ready  to  assume  their  responsibilities  effectively.  We  need 
to  educate  and  train  them  anytime,  anywhere  as  needed.  The  tools  used  to  support  training  and 
exercise  events  should  be  reusable  and  interoperable  to  cut  down  on  the  modelling  cost,  as  they 
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should  be  multi-resolution  to  optimize  their  use  at  different  levels  of  operations.  The  real  world 
operational  CCIS  systems  should  become  the  backbone  of  these  simulations.  Embedded  decision 
making  tools  could  make  them  valuable  during  real  operations. 
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NATO  Annual  Modelling  and  Simulation  Conference 
“C3I  and  Modelling  and  Simulation  Interoperability” 

Closing  Remarks 

Mr  Graham  G.  BURROWS,  Head,  NMSCO 
Conference  Committee  Chairman 

RTA  -  BP  25 

92201  Neuilly  sur  Seine,  France 

Mr  Burrows  provided  the  following  closing  remarks: 

Summary  of  initial  Key  Points  emerging  from  Conference: 

Modelling  and  Simulation  has  a  pivotal  role  in  every  phase  of  the  NATO  Transformation 
Conference. 

There  are  many  promising  approaches,  but  we  do  not  yet  have  good  interoperability  between 
M&S  and  C3I  systems. 

Knowledge  of  C3I  systems  architectures  and  dat/object  models  should  be  mandatory.  There  is 
still  much  education  to  be  done  in  C3I  and  M&S. 

Commercially  supported  open  standards  are  increasingly  being  used  as  add-ons  to  specific  M&S 
standards,  in  particular  web  services  and  XML.  But,  to  align  these  approaches,  overarching  methods  are 
needed. 

He  thanked: 

-  The  National  Hosts  (Turkey)  for  hosting  the  Conference  and  for  providing  excellent  support  and 
facilities. 

-  The  participants  for  attending,  providing  excellent  Papers  and  positive,  stimulating  questions  and 
comments. 

-  The  Interpreters  -  It  had  been  a  real  challenge  keeping  up  with  the  many  different  accents  and  speeds  of 
delivery,  but  as  usual  they  rose  to  the  challenge. 

He  announced: 

-  The  next  NATO  M&S  Conference  will  be  held  in  Germany,  on  7  and  8  October  2004  with  the  Theme  - 
M&S  to  Address  NATO’s  New  and  Existing  Military  Requirements. 

He  finally  wished  participants  a  safe  and  enjoyable  journey  home. 
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